O que há de novo no Postgres 19: uma análise aprofundada da versão beta

 (snowflake.com)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A versão beta traz REPACK CONCURRENTLY integrado ao core para grandes bancos de dados de produção, além de melhorias amplas em consultas de grafo por SQL, replicação lógica, VACUUM, desempenho e muito mais
  • Suporte a mesclagem e divisão de partições e sincronização de valores de sequência tornam mudanças de design e movimentação de dados em produção bem mais fáceis
  • O autovacuum passa a contar com workers paralelos e um sistema de pontuação por prioridade, melhorando a vazão e a visibilidade das tarefas de manutenção
  • Com a introdução de SQL/PGQ, passa a ser possível consultar dados existentes em formato de grafo sem abandonar o modelo relacional
  • O ponto principal não é um recurso isolado, mas a amplitude (breadth): avanços simultâneos em aplicações, operações, desempenho e escalabilidade

REPACK integrado por padrão

  • Em ambientes operacionais de longa duração, é recorrente a necessidade de recuperar bloat de tabelas, reescrever tabelas e reorganizar dados sem os locks normalmente associados a VACUUM FULL ou CLUSTER
    • Já existia um ecossistema de extensões para resolver esse problema, com pg_repack como principal destaque
  • O Postgres 19 incorpora o comando REPACK ao core, incluindo suporte a REPACK CONCURRENTLY
    • Espera-se que esse seja um recurso mais valorizado por usuários de produção do que o leitor médio de release notes imaginaria

Particionamento mais prático

  • O Postgres 19 adiciona suporte a mesclagem e divisão de partições
  • Estratégias de particionamento são escolhidas com informações incompletas, e quando carga de trabalho, retenção ou ritmo de crescimento de dados mudam, algumas partições podem ficar grandes demais ou pequenas demais
  • Com divisão e mesclagem, passa a ser possível evoluir o design ao longo do tempo sem precisar reconstruir tudo do zero
    • Exemplo de mesclar partições Q1 e Q2 em uma única partição: ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
    • Também é apresentado um exemplo de SPLIT PARTITION para dividir a partição de Q3 por mês

Replicação lógica mais madura

  • A replicação lógica é útil para migração, upgrade, sistemas de reporting, movimentação de dados, replicação seletiva e fluxos operacionais de alta disponibilidade
  • A maior melhoria é a sincronização de valores de sequência, permitindo que o assinante permaneça mais alinhado ao publicador
    • Sem replicar o estado da sequência, os dados são movidos, mas após o cutover podem surgir problemas porque o próximo ID gerado fica desalinhado
    • A publicação ganha suporte a ALL SEQUENCES, relatórios de erro de sincronização de sequência e melhorias no comportamento de atualização de assinaturas relacionadas a sequências
  • Agora é possível publicar todas as tabelas e excluir algumas com a cláusula EXCEPT
  • Quando necessário, wal_level = replica ativa automaticamente a replicação lógica, e o novo effective_wal_level mostra o comportamento real, reduzindo erros de configuração e aumentando a visibilidade

Autovacuum mais inteligente e mais visível

  • O autovacuum pode usar workers de vacuum paralelos, com controle global e por tabela
    • Exemplo de configuração global: ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
  • Um novo sistema de pontuação controla a ordem em que as tabelas são vacuumadas, melhorando a priorização das mais urgentes
    • Exemplo de ajuste por tabela: urgência 3.0 para vacuum baseado em inserts e urgência 0.5 para vacuum normal de update/delete
  • A nova view pg_stat_autovacuum_scores dá visibilidade ao processo de decisão
    • Mais detalhes nas views de progresso de vacuum e analyze, uso de memória e paralelismo em VACUUM VERBOSE e nos logs de autovacuum, além do novo log_autoanalyze_min_duration, reforçam a observabilidade da manutenção

Consultas de grafo por SQL

  • Foi adicionado SQL/PGQ (SQL property graph queries)
    • Entre as cargas de trabalho em que o modelo de vértices e arestas é útil estão detecção de fraude, recomendação, análise de redes, grafos de permissão, cadeia de suprimentos e organogramas
    • Exemplo de definição de grafo de propriedades: CREATE PROPERTY GRAPH store_graph com especificação de VERTEX TABLES e EDGE TABLES
  • A proposta não é abandonar o modelo relacional, mas adicionar mais uma forma de consultar os dados já existentes
    • Segue a mesma linha de JSONB, busca textual e extensões, que não exigiram mudanças forçadas de arquitetura
  • Do ponto de vista do desenvolvedor, isso permite usar consultas em grafo sem adicionar outro datastore, caminho de sincronização, superfície operacional ou mais um alvo para depurar às 2 da manhã

COPY mais útil

  • COPY FROM passa a suportar ignorar várias linhas de cabeçalho
    • Isso é útil ao processar CSVs exportados por fornecedores, ferramentas internas ou arquivos com metadados extras no topo
  • COPY FROM ganha ON_ERROR SET_NULL, permitindo transformar valores de entrada inválidos em null e oferecendo uma alternativa entre “falhar a carga inteira” e “pré-limpar tudo”
    • É mostrado um exemplo de carregamento de arquivo em que a coluna price mistura valores como 'N/A' e 'MISSING'
  • COPY TO pode gerar saída em formato JSON, incluindo um único array JSON, e também exportar tabelas particionadas diretamente (antes era necessário COPY (SELECT ...))
    • Exemplo para exportar uma tabela como array JSON válido: WITH (FORMAT JSON, ARRAY true)

Melhorias de conveniência em SQL

  • GROUP BY ALL agrupa automaticamente expressões da lista de seleção que não sejam agregadas nem de janela, deixando SQL exploratório e consultas de relatório mais limpos
  • Funções de janela passam a suportar IGNORE NULLS e RESPECT NULLS em lead, lag, first_value, last_value e nth_value
  • INSERT ... ON CONFLICT DO SELECT ... RETURNING foi adicionado para retornar de forma mais direta a linha em conflito em operações de upsert
  • UPDATE e DELETE FOR PORTION OF ampliam o suporte a operações temporais, junto com funções de tempo RANDOM() expandidas

Melhorias gerais de desempenho

  • O planner e o executor receberam muitas melhorias em anti-join, semi-join, constant folding, incremental sort em caminhos append, agregação antes de joins, cálculo de seletividade de joins e estatísticas de funções
  • O Postgres evolui para reconhecer melhor formatos comuns de consulta e reduzir trabalho desnecessário
    • Em alguns casos, parte da agregação é feita antes dos joins, diminuindo o número de linhas processadas
    • Mais casos de NOT IN e LEFT JOIN são convertidos em anti-joins eficientes
    • Há mais visibilidade de EXPLAIN para Memoize, melhor desempenho de ordenação com radix sort, verificações mais rápidas de constraints de chave estrangeira e uso de instruções SIMD na entrada de texto e CSV do COPY FROM
  • Em muitos casos, é possível obter comportamento melhor apenas com o upgrade, sem alterar o código da aplicação

Por que o Postgres 19 importa

  • O destaque não é um recurso isolado, mas a amplitude (breadth)
    • Para desenvolvedores de aplicações: consultas em grafo, sintaxe SQL aprimorada, melhorias em funções de janela e comportamento melhor de upsert
    • Para operadores: REPACK CONCURRENTLY, autovacuum melhorado, monitoramento ampliado, mudança online de checksum e maior visibilidade da replicação
    • Para quem prioriza desempenho: melhorias no planner, ganhos com SIMD, visibilidade de I/O assíncrono, verificação mais rápida de chaves estrangeiras e ordenação melhor
    • Para quem constrói sobre o Postgres: novos hooks, módulo de conselho ao planner, melhorias de extensões, busca de estatísticas de FDW e continuidade do investimento no ecossistema de extensões
  • Não se trata de uma evolução para uma única carga de trabalho ou persona, mas de um avanço simultâneo do Postgres como banco de dados e plataforma para aplicações, operações, análises e extensibilidade
  • Como ainda não é GA, este é o momento de testar: rodar aplicações, validar migrações, verificar extensões, conferir planos de consultas críticas e revisar fluxos de replicação lógica e manutenção

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • Já usei Postgres, Oracle, MS SQL Server e MySQL em projetos reais, e não usei SQLite a fundo, mas sei que é uma excelente opção
    Hoje em dia, por mim mesmo, sempre evito Oracle e MySQL/MariaDB
    O Postgres é excelente, mas eu gostaria que tivesse conexões leves e views materializadas atualizadas de forma síncrona. Mesmo que um pooler de conexões melhore a situação, o uso de memória por conexão simultânea ainda é anormalmente alto, e recursos como views indexadas do SQL Server permitem implementações elegantes, triviais e sempre corretas em cenários de dados complexos
    O SQL Server pode ser caro, mas em muitos casos vale o que custa, e escolher o armazenamento de dados com cuidado pode evitar muitos problemas no futuro

    • Para problemas de armazenamento relacional, uso principalmente SQLite e MSSQL
      Se for usar um provedor gratuito, é difícil superar o SQLite, e hoje ele dá conta da maioria dos casos de uso. Mas começa a desmoronar em backup, replicação e ferramentas. Se eu tiver que ser responsável pela disponibilidade do sistema e pela recuperação de desastres, não hesito em gastar dinheiro para reduzir o risco
      Se for pagar qualquer quantia, eu vou até o fim. A experiência de desenvolvimento em torno do MSSQL é incomparável, e acho que os projetos SQL no SSMS e no Visual Studio hoje em dia são muito melhores do que coisas como Entity Framework. Se ainda somar ferramentas de terceiros como o RedGate, dá para substituir pacotes de consultoria de milhões de dólares
      Eu não sugeriria subir um novo servidor Oracle ou DB2, mas se já existir um, provavelmente me oporia até o fim a refatorar só para eliminá-lo. Esses bancos de dados costumam vir acompanhados de uma enorme coleção de histórias de terror, e tentar reproduzir esses efeitos colaterais estranhos em um novo motor pode acabar destruindo o próprio negócio se não houver outra opção
    • Oracle é uma combinação de dor, sofrimento, alto custo, processos judiciais e miséria humana. Acho que já teria falido se não fosse por gerentes intermediários não técnicos que gostam de receber benefícios como boas festas ao comprar software caro
    • Até a própria Microsoft parece ter basicamente abandonado o SQL Server e estar gastando mais tempo melhorando vários produtos Postgres no Azure. Desde 2022, a última grande versão foi basicamente só a adição de alguns recursos de IA
      Como DBA, quando você faz muito trabalho pesado de DBA, o Postgres está em outra categoria em relação ao SQL Server. O Postgres é nativo de Linux e open source, então sua flexibilidade, observabilidade interna e operabilidade não têm comparação com o SQL Server
      No cenário técnico atual, considero o SQL Server praticamente morto. As empresas que ainda o usam são só organizações legadas centradas em Windows, e até essas estão diminuindo aos poucos
    • Eu realmente queria que existissem views materializadas com atualização síncrona. Em termos da Oracle, acho que estou falando de algo como “refresh on commit”
      Também seria bom ter uma opção de atualização adiada. A ideia é processar várias atualizações de uma vez, considerando apenas os registros alterados desde a última atualização, mas não sei exatamente como a Oracle faz isso tecnicamente. Acho que esse recurso seria uma adição fantástica em comparação com praticamente qualquer banco de dados OLTP open source
      Também estou bem curioso sobre o projeto OrioleDB: https://github.com/orioledb/orioledb/releases
      Alguns anos atrás, eu sofria bastante com vacuum por causa de muitas inserções e exclusões aleatórias contínuas em algo parecido com uma tabela temporária. Resolvi isso acumulando mais mudanças na RAM e depois dando flush na tabela para aumentar o número de linhas alteradas por página, mas deu bastante trabalho encontrar um bom equilíbrio
    • Embora o PostgreSQL seja um produto melhor, ele não tem a escalabilidade horizontal do MySQL/MariaDB. Por isso, se você precisa de um cluster fácil de configurar e lida com algo como uma grande loja de varejo online, o MySQL ainda pode ser útil

  • Como alguém que usa Postgres na área científica há mais de 15 anos, estou começando a me preocupar com a falta de armazenamento colunar no PostgreSQL
    À medida que os conjuntos de dados ficam maiores, as limitações do armazenamento do PG ficam cada vez mais evidentes. Várias extensões, como cetus, até podem oferecer essa funcionalidade, mas aí você passa a depender de que essas extensões continuem sendo suportadas, além de aumentar a complexidade

    • Fazendo uma propaganda um pouco descarada, venho trabalhando nesse problema como uma extensão há alguns meses: https://github.com/xataio/deltax
      No começo, eu achava que usar tabelas do Postgres como armazenamento e o executor do Postgres traria um overhead inerente alto demais, então pensei que, se desse para chegar no nível de desempenho do Timescale, já seria bem legal. Não imaginei que pudesse se aproximar de um banco de dados analítico dedicado
      Mas, à medida que o projeto avançou, o desempenho continuou melhorando, e agora passei a apoiar claramente a ideia de fazer cargas analíticas com Postgres + extensão
    • Se você espera isso, talvez tenha escolhido o banco de dados errado. Bancos de dados colunares são uma categoria separada
      É como se preocupar porque a Apple não vende máquinas de lavar
    • Do ponto de vista da ciência da computação, não sei bem como um banco de dados transacional implementaria isso em formato colunar. Em escala, a combinação Postgres + CDC + ClickHouse provavelmente é a opção mais forte para um banco analítico de verdade
    • Se os conjuntos de dados estão crescendo cada vez mais, parece melhor manter os dados novos no PostgreSQL e arquivar periodicamente os dados antigos em um banco de dados estilo data warehouse, mantendo o Postgres enxuto
      Hoje em dia, muitas empresas usam no aplicativo principal um banco de dados relacional junto com um banco chave-valor ou um armazenamento de documentos
    • Como usuário há 25 anos, acho que o estado atual já está bom. Ter mais coisas não significa necessariamente ser melhor, como o Redis mostra

  • Não sei por que ninguém mencionou que o PostgreSQL 19 vai introduzir suporte nativo a application-time temporal data com base no padrão SQL:2011: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

    • Surpreende que o texto original não tenha mencionado isso. Antigamente eu implementava isso adicionando manualmente triggers tcn e tabelas sombra _archive: https://www.postgresql.org/docs/current/tcn.html
      Se isso virar nativo, parece que vai ser realmente excelente, como a maioria das implementações do PostgreSQL
    • Também é uma pena que Query Hints só tenham sido mencionados de passagem. Houve uma discussão interessante sob um post anterior com título parecido
      https://news.ycombinator.com/item?id=48413655
    • É um recurso legal, mas sinceramente acho um pouco complicado de usar bem. E é preciso tomar cuidado para que PII não fique por muito tempo em algum temporal void

  • Não consigo dizer se este texto usa um estilo super-representado em dados de treinamento de LLM, ou se foi bastante polido com IA. Inclino mais para a segunda hipótese

    • “Polido” é gentil demais. O que mais incomoda é que as informações sobre o autor induzem ao erro. Não encontro craig-kerstiens no Hugging Face, e não há uma única frase neste texto que pareça ter sido digitada diretamente por um teclado
      Acho que quando o Claude escreve frases como “como alguém que faz X há muito tempo”, isso é um tipo de falha de alinhamento. Um LLM não deveria escrever como se tivesse experiência pessoal. Pessoas podem ter falado assim nos dados de treinamento, mas, mesmo que seja uma sequência de tokens estatisticamente plausível, acho que um LLM não deveria afirmar experiências de vida que não tem
    • Não há motivo para ser tão generoso. A Snowflake demitiu redatores técnicos dizendo que iria substituir por IA: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
    • Comentários desse tipo, de baixo esforço, apontando estilo e formatação, violam as diretrizes de discussão do Hacker News, e seria preciso tomar medidas para limpar a seção de comentários. Já está ficando ridículo
    • O Pangram classifica todo este texto como gerado por IA, mas não sei o quanto dá para confiar no Pangram. Queria ouvir o que outras pessoas pensam
    • Entendo que virou moda especular se algo usou IA. Mas, se há algo a criticar, acho mais útil criticar o resultado final

  • Gostei das melhorias em COPY e replicação lógica. Hoje faço backup do banco PG para uma instância sidecar do Databasus, e isso é mais pesado do que todo o backend + DB + Caddy
    Abaixo vai minha reclamação sobre o estilo de LLM
    Em vez de ler frases como “Só isso já mostra: havia uma necessidade real por parte dos usuários, e o ecossistema preencheu essa lacuna”, “Parece simples, mas resolve problemas reais de operação” e “Não muda o mundo, mas melhora os fluxos de trabalho de dados do dia a dia”, se Orwell estivesse vivo hoje talvez tivesse declarado analfabetismo em inglês e aprendido Klingon

  • Os recursos de banco de dados em grafo parecem interessantes, mas a sintaxe GRAPH_TABLE é horrível demais
    SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
    Isso lembra neo4j, mas em 2026 não acho que seja algo que uma ferramenta séria devesse copiar desse jeito
    No fim, o que me deixa curioso é a velocidade. Segurança em nível de linha é um recurso muito útil, mas tentar construir algo sério sobre a implementação do Postgres é temerário. O planner vira uma bagunça e o matching por linha destrói o desempenho

    • Isso não é uma sintaxe arbitrária criada pelo próprio Postgres
      É SQL/PGQ, derivado da linguagem Cypher do Neo4J e que agora faz parte do padrão SQL
    • Você está dizendo que, em segurança em nível de linha, o planner verifica linha por linha? Isso é exatamente Row-level security. De que outra forma ele verificaria se a linha passa pela política?

  • Seria bom se o PostgreSQL ganhasse compressão de bloco além de compressão de linha. Só compressão de linha tem efeito limitado demais
    Dá para colocar os dados em um pool ZFS e ativar compressão de bloco, mas, se houvesse suporte nativo, haveria menos carga de configuração e talvez o desempenho fosse melhor

  • GROUP BY ALL realmente faz muito sentido quando você para para pensar, e é interessante porque eu nunca tinha pensado nisso antes

  • De uma perspectiva mais próxima de DevOps, eu queria muito que o PostgreSQL finalmente suportasse upgrade in-place entre versões principais consecutivas
    A maioria das distribuições consegue lidar com a inconveniência de rodar a versão antiga e a nova ao mesmo tempo para o pg_upgrade, mas, usando Docker, fazer upgrade para uma nova versão principal é realmente doloroso

  • Fico feliz que GROUP BY ALL tenha sido adotado. Pelo que sei, é um conceito introduzido pelo DuckDB
    A documentação do DuckDB também diz que vários recursos foram introduzidos primeiro no DuckDB e depois adotados por outros sistemas, incluindo recursos como GROUP BY ALL
    https://duckdb.org/docs/lts/sql/dialect/friendly_sql