PostgreSQL 19 se aproxima com novidades para engenharia de dados

O que muda antes de atualizar

O PostgreSQL 19 Beta 3 saiu em 13 de agosto de 2026, e as release notes estavam completas em 18 de julho - ainda sujeitas a mudança, sem data de GA anunciada, mas pela cadência usual de setembro/outubro a versão final deve chegar em poucas semanas. A análise de Dimitri Fontaine cobre quebras de compatibilidade e novidades em SQL, todas testadas numa instância real da Beta 3.

A versão traz mais quebras de compatibilidade que o típico. O JIT fica desativado por padrão porque o modelo de custo era pouco confiável - quem depende dele em consultas analíticas precisa ligá-lo manualmente (jit = on). standard_conforming_strings fica sempre ativo, sem opção de desligar no servidor, e dumps antigos feitos com ele desligado não carregam limpos no PG 19 - é preciso reexportar com um pg_dump atual. A autenticação RADIUS é removida por ser considerada insoluvelmente insegura sobre UDP; MD5 agora emite aviso a cada login, passo rumo à remoção iniciada no PG 18, com migração recomendada para scram-sha-256.

Outras mudanças: o opclass padrão GiST para inet/cidr muda dos fornecidos pela extensão btree_gist para novas classes nativas, porque as antigas podiam excluir linhas válidas - pg_upgrade recusa clusters com esses índices até um REINDEX. CR/LF é proibido em nomes de banco, role e tablespace. max_locks_per_transaction dobra de 64 para 128, mas não é folga extra: quem ajustou o valor precisa dobrá-lo. default_toast_compression muda de pglz para lz4, alterando silenciosamente compressão e uso de CPU.

Novidades em SQL

A cláusula FOR PORTION OF faz em um único UPDATE a divisão de intervalos temporais que antes exigia atualizar a data final e inserir uma nova linha manualmente. INSERT ... ON CONFLICT DO SELECT ... RETURNING retorna a linha conflitante diretamente, com bloqueio e filtro opcionais - peça que faltava para padrões idempotentes de "upsert-and-fetch", já que DO NOTHING e DO UPDATE não devolvem a linha existente. Funções de janela como lead(), lag() e first_value() aceitam IGNORE NULLS, pulando nulos em vez de propagá-los - antes exigia truques de frame ou subconsultas.

ALTER TABLE ... ALTER CONSTRAINT ... [NOT] ENFORCED agora funciona para constraints CHECK (no PG 18 só valia para chaves estrangeiras), permitindo desligar completamente a verificação, inclusive para novas linhas - distinto de NOT VALID, que continua validando novas inserções. Reativar valida os dados existentes e recusa se houver violação. O novo comando REPACK unifica VACUUM FULL e CLUSTER e adiciona CONCURRENTLY, que evita o lock exclusivo - mas não é MVCC-safe, rejeita tabelas unlogged, particionadas, de catálogo e TOAST e sem chave primária, exige slot do novo max_repack_replication_slots e ainda toma um breve ACCESS EXCLUSIVE no fim.

Funções pg_get_role_ddl(), pg_get_tablespace_ddl() e pg_get_database_ddl() retornam os comandos para recriar objetos direto do catálogo, antes possíveis só via pg_dumpall ou scripts de terceiros. range_minus_multi() e multirange_minus_multi() subtraem faixas retornando um conjunto de fragmentos, sem exigir que a faixa subtraída fique numa ponta. random() ganha versões para date, timestamp e timestamptz, útil para dados de teste, e error_on_null() transforma o clássico bug silencioso do NULL inesperado em erro explícito na expressão.

SQL/PGQ e o caso MERGE PARTITIONS

O PG 19 implementa o SQL/PGQ (parte 16 do padrão SQL), permitindo consultar tabelas relacionais com sintaxe de grafos. CREATE PROPERTY GRAPH funciona como uma view: não há novo motor de armazenamento nem cópia de dados, e as permissões vêm das tabelas base. Consultas via GRAPH_TABLE são joins escritos em outra forma. Caminhos de comprimento variável (quantificadores como 1 a 4 saltos) ainda não funcionam - a gramática já entende o padrão, mas o planejador não foi implementado; para alcançabilidade e caminhos mínimos, WITH RECURSIVE continua sendo a ferramenta. Para o autor, a fundação carregada (catálogos, parser, reescritor) veio primeiro e as partes difíceis ficarão para depois - o mesmo padrão de decisão dos engenheiros sobre o que está pronto.

Esse padrão apareceu de forma dramática: em 27 de agosto, Alexander Korotkov reverteu todo o recurso ALTER TABLE ... MERGE/SPLIT PARTITIONS da branch - a segunda vez que ele é adiado no fim de um ciclo (a primeira foi no PG 17, em 2024). Uma thread aberta por Zsolt Parragi, da Percona, listou cinco problemas de design reproduzidos pelo autor: constraints CHECK evaporam silenciosamente no merge, colunas geradas armazenadas são recomputadas sem aviso, replicação lógica registra INSERTs fantasma sem DELETEs correspondentes, e publicações podem esvaziar-se sem notar. As release notes ainda listavam o recurso cinco dias depois do revert, então o binário não fará o que a documentação sugere. Para o autor, o adiamento é o processo funcionando - é possível quando engenheiros decidem o que sai, não um calendário prometido ao mercado.

Fora do escopo do artigo

O autor deixa para outro momento: as extensões pg_plan_advice e pg_stash_advice para estabilizar planos do planner - na avaliação dele, o recurso mais consequente da versão para OLTP; replicação lógica que agora replica valores de sequências e não exige mais reinício (wal_level efetivo sobe automaticamente); WAIT FOR para read-your-writes em réplicas; checksums de dados ativáveis com o servidor no ar; autovacuum paralelo (opt-in) com sistema de pontuação para priorizar tabelas; escalonamento automático de workers de I/O; e novas métricas de observabilidade como pg_stat_lock e pg_stat_recovery.