TimescaleDB lança Hypercore: compressão híbrida de séries temporais no PostgreSQL com até 98% de redução

O Hypercore não é só mais um algoritmo de compressão: é uma reengenharia do modelo de execução no PostgreSQL para séries temporais. Ele transforma chunks de ~1.000 linhas em estruturas híbridas, parte linha, parte coluna, onde cada coluna vira um array compactado com algoritmos especializados por tipo: delta-of-delta + simple-8b para timestamps (como no Gorilla), XOR + bit-packing para floats, RLE para strings repetidas e dicionário com compressão em duas camadas para JSONB. Isso só funciona porque o TimescaleDB controla a ordem física dos dados via segmentby e orderby, exigindo que o dev pense em agrupamento lógico antes de escrever a primeira linha, algo que o PostgreSQL puro não exige nem orienta.

A novidade real está na integração com o novo subsistema de I/O do PostgreSQL 18 (lançado em setembro/2025): o Hypercore entrega menos bytes por consulta, mas agora esses bytes são lidos até 3× mais rápido graças ao driver de armazenamento otimizado. O resultado prático? Em benchmarks recentes, consultas de time_bucket() ficaram 3,5× mais rápidas na versão 2.26, e agregações com metadados esparsos atingiram aceleração de até 289×, sem mudar uma linha de SQL. É otimização de baixo nível operando em cima de padrões de uso reais, não de benchmarks sintéticos.

Antes do Hypercore, a compressão do TimescaleDB já usava técnicas como delta encoding e RLE, mas era limitada a chunks inteiros e dependia fortemente da configuração manual de segmentby/orderby. Com o lançamento oficial em junho/2026, o Hypercore se torna o mecanismo padrão, não uma opção avançada. A mudança crítica está na execução vetorizada expandida (versão 2.27, maio/2026): agora filtros, UPDATEs e UPSERTs em dados comprimidos usam poda por Bloom filter, evitando descompressão completa de blocos irrelevantes. Isso muda o trade-off: antes, operações de escrita em dados antigos eram proibitivas; agora, são viáveis com ganhos de até 160× em cargas seletivas, um salto que transforma a compressão de recurso de custo em recurso de desempenho.

Para devs que rodam PostgreSQL em produção com dados de sensores, logs ou métricas, o Hypercore reduz o custo operacional sem sacrificar a DX: nenhuma mudança na stack (não precisa migrar para ClickHouse ou QuestDB), nenhuma nova linguagem de consulta, apenas ajuste nos parâmetros de hypertable. Mas exige rigor técnico: escolher um segmentby com cardinalidade entre 100, 10.000 valores por chunk é obrigatório, errar aqui gera compressão ruim e queries lentas. Também importa porque o TimescaleDB Enterprise, anunciado em abril/2026, já inclui Hypercore como feature-chave para ambientes regulados, onde controle total sobre dados e performance previsível pesam mais que simplicidade de implantação.