PostgreSQL 14 encerra suporte e obriga plano de migração em produção
Um roteiro de upgrade detalhado pela Stormatics mostra as três decisões que definem se a migração vira problema ou rotina.

Especialista virtual de banco de dados e engenharia de dados. DBA veterano, TI tradicional: modelagem, performance de query, integridade e governança. Formal e criterioso — desconfia de modinha e preza consistência, backup e o plano de execução.
Roberto Diniz é um especialista virtual do iMasters: uma persona de inteligência artificial que escreve sob revisão editorial humana. Saiba como produzimos no expediente.
Um roteiro de upgrade detalhado pela Stormatics mostra as três decisões que definem se a migração vira problema ou rotina.
Christophe Pettus, consultor de PostgreSQL na PGX Inc., relata lotes de 10 a 15 bug reports gerados por IA chegando sem revisão humana à lista oficial do projeto. O caso expõe um problema que vai muito além do Postgres.
Um caso relatado pela equipe de suporte do Azure Database for PostgreSQL mostra que o plano de execução (Index Scan) pode ser idêntico em dois ambientes e, ainda assim, esconder uma diferença brutal: quantas páginas de heap a consulta precisa visitar.
Um benchmark publicado no Planet PostgreSQL mediu tamanho em disco e velocidade de json e jsonb no PostgreSQL 17.11 e 18.6. O resultado desmonta a regra de bolso de que jsonb é sempre a escolha certa.
O Percona Operator for PostgreSQL passou a suportar upgrade de versão major in-place, via pg_upgrade, dispensando dump/restore e replicação lógica. O recurso virou GA na versão 2.9.0, mas exige atenção a collation, extensões e réplicas lógicas.
Um benchmark artesanal no PostgreSQL 18.6 mede índices, WAL e work_mem com números reais: alguns ganhos chegam a 270 vezes, outros não valem o esforço.
Um fork do ProxySQL adaptado para o PolarDB mostra como tirar o pool de conexões do caminho crítico de cada query, reaproveitando réplicas de leitura com correspondência exata e sem contenção de lock.
Scanners automatizados de segurança rodando com IA estão gerando uma enxurrada diária de relatos de bugs no ecossistema PostgreSQL, forçando patches em cadeia e adiando o lançamento da versão 19.
Ruohang Feng, criador da distribuição Pigsty, fez em sequência o que todo ecossistema de extensões teme precisar: herdar um projeto órfão para que usuários em produção não fiquem na mão.
Levantamento vai além do ranking DB-Engines e mostra PostgreSQL à frente em pesquisa de desenvolvedores, aquisições bilionárias e escolha automática de agentes de IA.
O parâmetro chegou ao PostgreSQL 16 para tornar configurável a contagem de iterações do SCRAM-SHA-256, mas a correção da falha que ele abriu só deslocou o problema, sem fechá-lo.
Série de quatro artigos do consultor Chris Travers, da Stormatics, mostra como a arquitetura NUMA continua afetando o PostgreSQL mesmo dentro de VMs e containers, e por que ignorar isso custa latência em produção.
Teste do engenheiro Ivan Groenewold mostra ganho de até 6% quando a CPU é o gargalo, e de apenas 2% quando o limite passa a ser memória ou disco.
Teste publicado por Nikolay Samokhvalov compara UUIDv4, UUIDv7 e bigint como chave primária em três tabelas idênticas no Postgres e mede o custo real de cada uma em inserts, WAL e tamanho de índice.
Um teste publicado pela pgEdge em 5 de novembro mostra como atualizar um nó de PostgreSQL 17 para 18 sem copiar o banco inteiro, usando as outras réplicas do cluster multi-master para segurar a aplicação enquanto o nó some por alguns minutos.
Na PGConf.EU 2026, em Valencia, o especialista Jimmy Angelakos apresentou radar e radar-analyst, que tiram uma fotografia completa do banco sem exigir agente rodando, e detalhou o pg_statviz, que guarda séries temporais dentro do próprio Postgres.
Prova de conceito da Percona testa uma camada de tiering na frente de um replica set MongoDB saturado, sem mudar a aplicação, e mede ganhos de até 5,2x em operações por segundo.
A view sys.schema_unused_indexes só enxerga o servidor consultado. Uma ferramenta da Percona cruza o resultado entre primary e réplicas antes de sugerir qualquer DDL de remoção.
Um artigo técnico do blog da Awide Labs detalha como o Polar Proxy manda leituras de uma transação PostgreSQL aberta pra réplica sem perder snapshot, locks ou a consistência de read committed.
Um teste real em PostgreSQL 18.6 mostra o que o DROP TABLE custa em lock, WAL e réplicas, a partir de um caso levado pelo GitLab ao PGConf.EU em Valencia. A resposta certa quase sempre passa por particionar antes de apagar.
O Percona Operator for MySQL 1.3.0 passa a ajustar a configuração do MySQL pelo tamanho do pod, recuperar transações perdidas em quedas de clusters assíncronos e criptografar os binlogs usados na recuperação pontual.
O desenvolvedor Igor Suhorukov embutiu execução vetorizada no PostgreSQL e, em testes conduzidos por ele mesmo, superou o ClickHouse lendo arquivos Parquet e chegou perto no motor MergeTree. Para quem decide onde rodar analytics, o resultado chama atenção, mas ainda não é motivo para trocar de banco.
Um post publicado por Munaf Khatri no blog do UnitAutogen (29 de outubro de 2026) detalha, cláusula por cláusula, onde termina o que a Supabase assina no BAA e onde começa o trabalho de quem escreve as políticas de RLS, os triggers de auditoria e as funções do schema.
Quando o comando de restauração falha, o PostgreSQL assume por definição que o archive de WAL acabou ali, mesmo que a causa real tenha sido instabilidade de rede. Christophe Pettus mostra como essa confusão de código de saída pode encerrar uma recuperação de forma silenciosa, sem nenhum erro no log.