2026-06-30

Olhando para o futuro do Postgres 19

Omissões percebidas e recursos notáveis do roadmap do PG19/PG

Comentadores observam que o artigo dá pouca ênfase a adições importantes como tabelas temporais nativas com tempo de aplicação (estilo SQL:2011) e query hints, que antes tinham gerado interesse.
A nova consulta de grafos (SQL/PGQ) chama atenção; alguns acham a sintaxe desajeitada e questionam o desempenho, especialmente considerando problemas anteriores do planner com segurança em nível de linha.
GROUP BY ALL é amplamente elogiado como uma pequena, mas muito útil, melhoria de usabilidade do SQL.
Melhorias em COPY e replicação lógica são bem-vindas para backups mais leves; alguns já executam instâncias sidecar pesadas apenas para backup.
I/O assíncrono no PG18 foi citado como um forte motivador para sair do 16.

Conteúdo gerado por IA e qualidade da discussão no HN

Um grande subthread debate se o post foi escrito por LLM. Alguns confiam em ferramentas como Pangram; outros enfatizam que esses detectores não são prova confiável.
Várias pessoas estão frustradas com o que veem como prosa genérica de “LLM slop” se tornando comum no HN, com muitos blogs diferentes agora compartilhando o mesmo tom e estrutura.
Outros argumentam que reclamações meta sobre IA têm menos valor do que se engajar com conteúdo técnico, embora defensores digam que identificar trabalho não original, “lavado” por IA, está alinhado com as normas do HN.
Há menção de que a Snowflake demitiu redatores técnicos, citando IA, e preocupações com alegações enganosas de autoria humana.

Postgres vs. outros bancos de dados

Muitos usuários em produção estão entusiasmados com o Postgres, mas ainda querem:
- Conexões leves (processo por conexão é visto como pesado em comparação com servidores com threads).
- Views materializadas / indexadas mantidas sincronicamente, como no SQL Server.
O SQL Server é elogiado por views indexadas, snapshot isolation, ferramentas fortes (SSMS, Visual Studio, RedGate) e índices columnstore, embora alguns considerem seu ecossistema envelhecido, a dependência de Windows dolorosa e a semântica do MERGE problemática.
As críticas ao MySQL/MariaDB incluem implementação fraca de JSON, falta de DDL transacional/merge/índices parciais, problemas de rigor, comportamento histórico incorreto de tipos/UTF-8 e dores com replicação/DDL.
O Oracle é fortemente criticado por semânticas como string vazia igual a NULL e pelo peso comercial, jurídico e de fornecedor.

Escalabilidade, mecanismos de armazenamento e analytics

Vários usuários querem mecanismos de armazenamento plugáveis: LSM (por exemplo, semelhante ao RocksDB), append-only, ou compressão nativa por coluna/bloco.
Exemplos citados incluem a Salesforce executando Postgres com LSM, OrioleDB (ainda exigindo patches no core) e extensões columnar/analíticas como cetus ou uma nova extensão estilo Delta.
Há tensão entre:
- Aqueles que querem que o Postgres evolua com armazenamento plugável/columnar para lidar com cargas científicas/analíticas muito grandes no próprio sistema.
- Aqueles que argumentam que bancos OLAP columnar são uma categoria diferente e aconselham usar Postgres para OLTP e warehouses separados (ClickHouse, DuckDB, etc.) via CDC ou ETL.

Operações, ecossistema e cultura

Atualizações de versão principal in-place continuam sendo um ponto doloroso, especialmente com Docker.
O modelo de conexão/processo versus o modelo de threads do MSSQL é debatido em termos de escalabilidade, robustez e cache de planos.
Alguns veem o Postgres efetivamente substituindo o MySQL para novas stacks de apps (“PHP/MySQL → Python/Postgres”) e observam que grandes plataformas de dados (Snowflake, Databricks, ClickHouse) agora oferecem Postgres gerenciado, o que é visto como um sinal dos tempos.
Um usuário pede recursos avançados para aprender Postgres; a resposta é que a superfície de funcionalidades é muito ampla, então as recomendações dependem bastante dos interesses específicos.