O Retrato do Mercado em 2025

A previsibilidade é o alicerce de qualquer ambiente de missão crítica. No entanto, os dados brutos da pesquisa Postgres em Foco 2025 revelam um cenário desafiador: 20,8% das empresas brasileiras ainda operam com o PostgreSQL 12 ou versões anteriores em produção.

Com o PostgreSQL 12 atingindo o seu estágio de End of Life (EOL), essa permanência deixa de ser uma escolha técnica de estabilidade e passa a ser um risco estratégico de continuidade de negócio.

O Risco Real da Inércia Operacional

Manter uma versão descontinuada significa operar sem o suporte do grupo global de desenvolvimento do PostgreSQL. Para uma pessoa especialista ou gestora técnica, isso se traduz em três frentes de risco:

• Segurança: Ausência de patches para novas vulnerabilidades (CVEs).
• Conformidade: Dificuldade em manter certificações de segurança de dados em ambientes defasados.
• Custo de Oportunidade: Perda de eficiência em relação às otimizações de performance introduzidas nas versões 13 a 18.

Upgrade como Alavanca de Maturidade

Dentro da Matriz de Maturidade PostgreSQL, o processo de atualização não deve ser encarado como um “mal necessário”, mas como uma evolução planejada.

• Pós-v12: Migrar para versões recentes permite acessar melhorias críticas em particionamento e na deduplicação de índices B-tree, o que reduz diretamente o consumo de storage e melhora o tempo de resposta.
• Visão Sistêmica: O upgrade é a oportunidade de realizar um Health Check profundo, identificando gargalos e desperdícios que muitas vezes são mascarados por versões antigas.

Checklist Tático: Como sair do Postgres 12 com Segurança

Para garantir que a migração seja previsível e eficiente, a Timbira recomenda focar nos seguintes pontos de controle:

• Planejamento de Salto (Jump): Avaliar se a migração será direta para a versão mais recente (v18) ou se há dependências arquiteturais que exigem passos intermediários.
• Análise de Compatibilidade: Validação de extensões e plugins do ecossistema que podem ter mudado o comportamento. Revisão das notas de lançamento que trazem informações sobre regressões e pontos de atenção a considerar no planejamento. Validação de Performance: utilizar o EXPLAIN e métricas de observabilidade para comparar o comportamento de consultas críticas entre a versão 12 e a nova versão.

Do Operacional ao Estratégico

Os dados da pesquisa mostram que a “Dificuldade na atualização” é um dos maiores entraves do mercado. No entanto, a evolução do DBA para o papel de Data Sustainability Engineer (DSE) exige essa transição do operacional reativo para o tático-estratégico.

Sair do Postgres 12 é o primeiro passo para garantir que o seu banco de dados não seja apenas uma ferramenta técnica, mas um ativo que impulsiona a inovação e a vantagem competitiva da sua empresa.

Conte conosco!

Precisa de apoio para planejar sua migração? Entre em contato com a Timbira. Nossos especialistas podem te ajudar a planejar e executar a migração com segurança, sem complicações e com o mínimo de interrupções.

[Quero falar com a Timbira]

Quando instalamos o PostgreSQL, as configurações padrão são extremamente conservadoras para garantir que o banco rode em quase qualquer hardware. No entanto, para empresas que buscam crescimento tecnológico sustentável, o “padrão” é o primeiro gargalo a ser superado.

A lógica por trás dos Buffers

No pilar de Previsibilidade, entender o Shared Buffers é entender a saúde do I/O (entrada e saída de dados). Se o seu banco precisa buscar dados no disco constantemente porque eles não estão no cache de memória, a latência sobe e a experiência do usuário cai.

• O que é: É a área de memória utilizada pelo PostgreSQL para armazenar páginas de dados recentemente ou frequentemente acessadas.
• O Limite do Padrão: O shared_buffers costuma vir configurado com meros 128MB. Em ambientes de alta escala, esse valor é insuficiente e pode resultar em um Buffer Cache Hit Ratio baixo, aumentando a quantidade de leituras em disco e gerando maior pressão de I/O.

Alinhando com a Matriz de Maturidade

Dentro da Matriz de Maturidade PostgreSQL, a gestão de memória separa o nível operacional do nível tático-estratégico.

1. Nível Operacional: Utiliza as configurações default e sofre com lentidões inexplicáveis quando a carga aumenta.
2. Nível Tático: Ajusta o shared_buffers de acordo com o contexto da infraestrutura (frequentemente em torno de 25% da RAM, como regra geral), monitora o Background Writer e entende o impacto de checkpoints no desempenho do sistema.
3. Nível Estratégico: Analisa o ecossistema completo, incluindo a interação entre o cache do PostgreSQL e o cache do sistema operacional, buscando previsibilidade de desempenho e melhor custo-benefício de infraestrutura.

Previsibilidade e Upgrades: O que considerar?

Ao planejar um upgrade, seja ele corretivo ou de nova funcionalidade, a revisão das configurações de memória deve fazer parte do processo. Novas versões do Postgres podem introduzir melhorias na gestão de memória que permitem uma utilização ainda mais eficiente do hardware.

Configurar o shared_buffers não é apenas alterar um número no arquivo postgresql.conf; trata uma decisão tática para sustentar ambientes confiáveis ao longo do tempo.

Conte conosco!

Se você está buscando otimizar o desempenho e a confiabilidade do seu banco de dados PostgreSQL, a Timbira está aqui para ajudar. Podemos oferecer orientação especializada para automatizar tarefas repetitivas, implementar melhores práticas e garantir que seu banco de dados esteja funcionando de forma eficiente e segura.

[Quero falar com a Timbira]

No modelo tradicional de administração de bancos de dados, a reação a uma query lenta costuma ser quase mecânica: identificar o gargalo e criar um índice. No entanto, à medida que os ambientes escalam e a complexidade dos dados aumenta, essa abordagem puramente operacional torna-se insuficiente e, muitas vezes, perigosa. A transição do DBA para o papel de DSE exige uma mudança de mentalidade: sair da reatividade e entrar na engenharia de previsibilidade. O alicerce dessa evolução é o domínio profundo sobre como o PostgreSQL decide executar uma consulta, o Cost-Based Optimizer (CBO). 

O Motor por Trás da Decisão: Como o CBO Calcula o Custo

O otimizador do PostgreSQL não escolhe um caminho de execução por “intuição” ou simples regras fixas. Ele é um motor matemático que busca o plano de menor custo total. Para o DSE, entender o EXPLAIN vai muito além de ler o output; trata-se de compreender as variáveis que alimentam o planejador.

O custo no PostgreSQL é uma unidade abstrata, mas diretamente proporcional ao esforço de hardware. O planejador utiliza constantes de custo para ponderar diferentes operações:

• seq_page_cost (padrão 1.0): O custo de buscar uma página de dados sequencialmente no disco.
• random_page_cost (padrão 4.0): O custo de buscar uma página de forma não sequencial. Em ambientes com SSDs modernos ou NVMe, manter o padrão de 4.0 pode induzir o otimizador a evitar índices injustificadamente, pois a diferença real entre acesso sequencial e aleatório é muito menor do que em discos magnéticos.
  +1
• cpu_tuple_cost (padrão 0.01): O custo de processar cada linha (tupla).

Quando você executa um EXPLAIN ANALYZE, o PostgreSQL compara as estimativas com a realidade. Se o custo estimado é baixo, mas o tempo real é alto, o problema geralmente reside em estatísticas obsoletas ou parâmetros de custo desalinhados com a infraestrutura de hardware.

Aplicação Prática: Além do Index Scan

Imagine um cenário onde o volume de dados cresce 20% ao mês. O “operador” confia que o índice criado hoje resolverá o problema para sempre. O DSE utiliza o EXPLAIN para validar a seletividade.

SQL

— Analisando a saúde de uma consulta crítica

EXPLAIN (ANALYZE, BUFFERS)

SELECT order_id, customer_id 

FROM orders 

WHERE order_date > CURRENT_DATE – INTERVAL ’30 days’

AND status = ‘shipped’;

Ao analisar o output, o DSE observa o filter versus o index cond. Se o otimizador opta por um Sequential Scan mesmo existindo um índice, o DSE não “força” o índice; ele investiga se o random_page_cost está punindo demais a escolha do índice ou se a distribuição de dados (n_distinct na pg_stats) está informando ao planejador que a maioria das linhas satisfaz o critério, tornando o scan sequencial mais barato.

Impacto Estratégico e Sustentabilidade

Ignorar a mecânica do CBO gera o que chamamos de degradação silenciosa. Uma query que hoje performa bem com 1 milhão de linhas pode atingir um “ponto de inflexão” onde o otimizador muda drasticamente o plano de execução ao atingir 10 milhões de linhas, causando quedas súbitas de performance em produção.

Para a gestão, isso se traduz em risco operacional e custos imprevisíveis de cloud (consumo excessivo de CPU e I/O). O DSE atua na Matriz de Maturidade ao garantir que o ambiente seja escalável por design, e não por força bruta de hardware.

Checklist de Engenharia para o DSE

1. Sincronia de Hardware: O random_page_cost reflete a realidade do seu storage (SSD vs HDD)?
2. Qualidade das Estatísticas: O default_statistics_target é suficiente para colunas com alta variação de dados (skewed data)?
3. Análise de Buffers: Você utiliza EXPLAIN (BUFFERS) para medir o impacto real no cache (shared buffers), minimizando leituras físicas?
4. Previsibilidade: Você simula planos de execução com volumes de dados projetados para os próximos 12 meses?

Quer garantir que seu PostgreSQL escaneie qualquer escala sem surpresas?

Dominar o Cost-Based Optimizer é o que separa o profissional que “apaga incêndios” daquele que projeta sistemas resilientes. Ao entender como o PostgreSQL quantifica o esforço de processamento, o DBA evolui para o papel de Data Sustainability Engineer, assumindo uma postura estratégica que garante que o banco de dados permaneça eficiente, previsível e sustentável, independentemente da escala que o negócio alcance.

Precisa de um apoio sustentável para os seus ambientes PostgreSQL?

[FALE CONOSCO!]

Você ainda evita CTEs no Postgres por medo da materialização? Se a sua base de conhecimento parou no PostgreSQL 11, você está deixando a performance na mesa.

Otimizar consultas modernas exige entender onde termina a organização de código e onde começa a barreira de otimização. Antigamente, a escolha entre uma subquery e uma CTE era simples: uma era rápida, a outra era legível. Hoje, essa linha se tornou tênue. Para o especialista, a pergunta não é mais “qual é o mais bonito”, mas sim: “como o Planner vai reescrever o meu SQL por baixo do capô?”.

Neste artigo, vamos colocar Subqueries, CTEs e Views frente a frente, analisando como o motor do Postgres evoluiu para tratar essas estruturas e qual delas realmente escala quando o volume de dados deixa de ser trivial.

A Queda do Muro: CTEs (WITH queries)

Durante anos, o Postgres tratava toda CTE como uma “Optimization Barrier”. O banco executava a query interna, salvava o resultado em disco/memória (materialização) e só então seguia adiante.

• A Evolução: Desde a versão 12, o Postgres se tornou inteligente. Se sua CTE for simples, o otimizador pode decidir fazer o inline dela, fundindo-a com a query principal como se fosse uma subquery.
• O Veredito do Especialista: Use CTEs para organizar fluxos lógicos complexos sem medo, mas monitore o EXPLAIN. Se precisar forçar o comportamento antigo por questões de performance específica, o comando WITH cte_name AS MATERIALIZED (…) é sua ferramenta de precisão.

Subqueries: O “Inline” Nativo

Subqueries são o terreno seguro para o otimizador. Como elas não têm a promessa de isolamento das CTEs, o Postgres tem liberdade total para “achatar” a consulta, reordenar JOINS e aplicar filtros no nível mais baixo possível.

• O Comportamento: Elas são quase sempre transformadas em sub-joins.
• O Risco: O custo aqui é humano. Consultas aninhadas em excesso tornam a manutenção um pesadelo e escondem erros de lógica que uma CTE deixaria óbvios.

Views: A Abstração que Pode Cobrar Juros

Views não são tabelas físicas; elas funcionam como atalhos lógicos para consultas. Quando você consulta uma View, o Postgres expande aquela definição dentro da sua query antes de otimizar.

• O Perigo do “Nesting”: O problema surge quando uma View chama outra View, que por sua vez faz um JOIN com uma terceira. O plano de execução pode explodir em complexidade, tornando impossível para o otimizador escolher o melhor índice.
• A Boa Prática: Views são para interface e segurança. Se a performance degradar, talvez seja hora de considerar uma Materialized View (com uma estratégia de refresh sólida) ou transformar a lógica em uma função.

O Raio-X da Decisão

O EXPLAIN ANALYZE é seu único juiz

A evolução do PostgreSQL eliminou o antigo “imposto de performance” que muitas vezes penalizava um SQL mais organizado e legível. Hoje é possível escrever código limpo sem abrir mão de eficiência.

Ainda assim, decisões técnicas devem ser baseadas em evidências — não em suposições. Não presuma que uma estrutura é melhor do que outra. Execute, meça e obrigue o banco a revelar o plano de execução.

No fim, é o EXPLAIN ANALYZE que determina o que realmente é mais eficiente.

Se você enxerga um CTE Scan no seu plano de execução onde esperava um Index Scan, você acabou de encontrar onde sua query está perdendo a guerra contra o tempo.

Quer receber mais conteúdos como esse?

Assine nossa newsletter. Menos “Hello World”, mais engenharia de verdade direto na sua caixa de entrada.

[Quero receber conteúdos de PostgreSQL!]

Se em 1998 o “Cadê?” ou o “Google Beta” eram o topo da tecnologia, hoje enfrentamos uma explosão de dados e ecossistemas em expansão que exigem mais do que apenas “manter o banco no ar”.

Como apresentado pela nossa CEO, Karin Keller, na palestra “A Jornada de DBA para DSE”, estamos navegando em novos mundos. Para o Administrador de Bases de Dados (DBA), a questão não é se a profissão vai acabar, mas sim como ela está evoluindo para o papel de Data Sustainability Engineer (DSE).

O que é o Data Sustainability Engineer?

Enquanto o DBA tradicional foca na manutenção e operação diária (reativa e de curto prazo), o DSE foca no crescimento sustentável dos ambientes de dados. É uma abordagem proativa, de médio e longo prazo, onde a eficiência, a escalabilidade e a inovação contínua são os pilares.

O Caminho da Evolução: Nível Tático e Estratégico

Para percorrer esta jornada, o DBA em evolução deve apoiar-se em competências fundamentais (Soft e Hard Skills) extraídas da prática e da documentação oficial do PostgreSQL, por exemplo:

1. Observabilidade e Predição (Hard Skill)

Um DSE não espera pelo alerta de “disco cheio”. Ele utiliza os recursos do Capítulo 28 da Doc do Postgres para criar uma camada de telemetria.

• Ação DSE: Implementar monitorização que analise tendências de crescimento e comportamento de queries (pg_stat_statements), garantindo que o ambiente seja sustentável antes mesmo do pico de tráfego.

2. Automação e Eficiência (Hard Skill)

A sustentabilidade passa por fazer mais com menos. O uso inteligente do Autovacuum (Capítulo 24.1) e do particionamento de tabelas não é apenas sobre performance, é sobre reduzir o “bloat”, economizar IOPS e, consequentemente, reduzir custos operacionais (FinOps).

3. Visão Estratégica e Comunicação (Soft Skill)

De acordo com a metodologia da Timbira, o DSE precisa ter uma comunicação clara e colaboração multidisciplinar. Já não basta dizer “o banco está lento”; é necessário explicar ao negócio como a arquitetura de dados suporta a estratégia da empresa e como as inovações (como IA e pgvector) podem gerar valor.

Os 10 Mandamentos do DSE (Skills para o Futuro)

Para quem deseja evoluir nesta carreira, estes são os pontos-chave apresentados na palestra:

1. Saber Aprender: A tecnologia é exponencial.
2. Visão Estratégica: Alinhamento com o negócio.
3. Comunicação Clara: Traduzir o técnico para o executivo.
4. Pensamento Sistémico: Ver o ecossistema, não apenas a tabela.
5. Integração: Trabalhar com equipes de Dev e SRE.
6. Domínio Profundo do PostgreSQL: Conhecer a fundo a documentação oficial.
7. Automação: Eliminar tarefas repetitivas.
8. Observabilidade: Dados sobre os dados.
9. Segurança: Governança e Compliance (LGPD).
10. Desenvolvimento: Entender o ciclo de vida da aplicação.

O Horizonte da Timbira

Na Timbira, acreditamos que o futuro do PostgreSQL é sustentável. O DSE é o guardião dessa sustentabilidade, garantindo que os dados não sejam um fardo, mas o combustível para a inovação.

O DBA que hoje se dedica a entender o PostgreSQL a nível tático e estratégico, preparando-se para os desafios de escala e governança, é o profissional que liderará as infraestruturas de amanhã.

Faça parte da nossa newsletter e receba mais conteúdos como esse no seu e-mail.

É comum que empresas cheguem a um ponto de inflexão. O volume de dados cresce, a complexidade das consultas aumenta e, de repente, aquele time que antes “dava conta do recado” começa a viver em um ciclo interminável de apagar incêndios.

Nesse cenário, a reação instintiva de muitos gestores é buscar o aumento do alcance operacional através de novas contratações. Mas será que o que sua empresa precisa hoje é de mais pessoas no time ou de uma nova perspectiva estratégica?

Entendendo os Modelos de Apoio Tecnológico

Antes de decidir como expandir sua capacidade, é fundamental entender que nem toda contratação externa funciona da mesma forma. A escolha errada pode gerar um descompasso entre a expectativa do gestor e a entrega técnica.

• Body Shop: Focado na alocação de profissionais por hora para funções operacionais, onde o cliente detém a liderança técnica.
• Outsourcing: A terceirização de um processo completo, onde a responsabilidade pela entrega de um serviço específico é transferida para o parceiro.
• Consultoria Especializada: Atua como um guia estratégico-tático, focando em diagnóstico, arquitetura e evolução do ambiente como um todo.

Se você quiser aprofundar o entendimento de cada um desses modelos, vale a pena conferir este guia detalhado sobre a diferença entre Body Shop, Outsourcing e Consultoria.

O Papel do Banco de Dados na Estratégia de Negócio

Na maioria das vezes, o banco de dados é visto apenas como uma ferramenta técnica, um repositório. No entanto, ele deve ser compreendido como um ativo estratégico capaz de impulsionar a inovação e influenciar decisões de negócio.

Quando focamos apenas no modelo operacional de alocação, corremos o risco de ignorar a visão sistêmica necessária para que o PostgreSQL se torne uma vantagem competitiva real para a organização.

A Diferença entre “Executar Tarefas” e “Construir Maturidade”

Para entender se o seu modelo atual ainda faz sentido, vale analisar três pilares fundamentais da engenharia, resumidamente:

1. Previsibilidade vs. Reatividade

No modelo puramente operacional, o foco está em resolver o problema que acabou de acontecer. Uma abordagem mais madura foca na Previsibilidade. Isso envolve a análise de indicadores e a manutenção preventiva para que os incidentes sejam antecipados, reduzindo desperdícios e riscos estruturais.

2. Evolução da Equipe

O papel do Administrador de Banco de Dados (DBA) está evoluindo. O mercado caminha para o conceito de DSE (Data Sustainability Engineer), um profissional focado na sustentabilidade e saúde de longo prazo do ambiente. Um modelo de gestão eficiente deve apoiar o DBA nessa transição, preparando-o para os desafios futuros.

3. Visão 360º do Ecossistema

Operar o PostgreSQL em escala exige domínio sobre os quatro pilares da engenharia: Arquitetura, Desenvolvimento, Segurança e Operação. Sem essa visão integrada, o que chamamos de Postgres 360°,  as decisões técnicas podem se tornar reativas, gerando ambientes defasados e riscos de segurança.

O Próximo Passo na Maturidade de Dados

Identificar lacunas técnicas é o primeiro passo para quem deseja operar com qualidade e escala. O objetivo final não é apenas ter alguém para “cuidar do banco”, mas garantir que a infraestrutura de dados suporte o crescimento da organização de forma previsível e segura.

Quando a gestão de dados sai do campo da “mão de obra” e entra no campo da “inteligência”, o PostgreSQL deixa de ser um custo e passa a ser o motor da eficiência operacional.

Precisa de um apoio sustentável para os seus ambientes PostgreSQL?

[FALE CONOSCO!]

Saiu ontem, 12 de fevereiro de 2026, a atualização PostgreSQL 18.2! Como toda minor release, o foco é em correções de segurança e bugs, sem alterações no formato dos dados, o que facilita o upgrade.

Aqui estão os destaques do que mudou da 18.1 para a 18.2, com base na documentação oficial:

Segurança (Correções de CVEs)

A versão 18.2 corrige vulnerabilidades importantes que podiam permitir execução de código arbitrário:

• CVE-2026-2004: Correção em estimadores de seletividade no contrib/intarray que podiam ser abusados. Agora, é necessário privilégio de superusuário para anexar estimadores não nativos a operadores.
• CVE-2026-2005: Correção de buffer overrun em funções de decriptografia PGP no contrib/pgcrypto.
• CVE-2026-2006: Ajuste na validação de comprimentos de caracteres multibyte para evitar estouro de buffer.
• CVE-2026-2007: Correção no contrib/pg_trgm para lidar com casos onde a conversão para minúsculas resulta em mais caracteres do que o original (comum em alguns locales).

Correções e Melhorias

• Índices no ltree: Foi corrigida uma inconsistência no case-insensitive matching. Atenção: Se você usa ltree, pode ser necessário reindexar após a atualização.
• Query Planner: Resolvidos problemas onde o planejador falhava ou gerava planos ineficientes em queries com chamadas duplicadas de funções de janela (window functions) ou subqueries complexas.
• I/O e Performance: Introdução do novo parâmetro file_extend_method. Ele permite contornar problemas com o posix_fallocate() em sistemas de arquivos específicos como BTRFS ou versões antigas do XFS.
• Replicação Lógica: Correções de race conditions que podiam invalidar slots de replicação recém-criados ou causar perda de transações em falhas de workers paralelos.
• Backup Incremental: Correção de um erro no pg_combinebackup que impedia a restauração de backups incrementais de tabelas maiores que 1GB caso tivessem sofrido truncamento por VACUUM.

Devo atualizar agora?

Sim. As minor releases do PostgreSQL não alteram o formato dos dados; elas focam exclusivamente na correção de bugs e vulnerabilidades. Isso torna o processo de atualização simples, seguro e com baixo impacto operacional, exigindo apenas a substituição dos binários e a reinicialização do serviço, sem necessidade de pg_upgrade

Dica de Ouro

Antes de rodar em produção, sempre teste o comportamento da sua aplicação em um ambiente de staging, especialmente se você utiliza extensões específicas como o PostGIS.

Comunicado Importante!

O PostgreSQL Global Development Group emitiu um alerta importante no dia 16 de fevereiro de 2026. Foram identificados problemas nas minor releases publicadas recentemente (em 12/02/2026), o que alterou a recomendação oficial de atualização para toda a comunidade.

As versões lançadas no dia 12 de fevereiro, 18.2, 17.8, 16.12, 15.16 e 14.21, introduziram regressões que podem afetar a estabilidade do ambiente. Em resposta, a comunidade agendou uma liberação extraordinária (“out-of-cycle”) para corrigir esses pontos.

Se você ainda não atualizou seus servidores para as versões citadas acima, a orientação é aguardar.

Uma nova leva de atualizações está programada para o dia 26 de fevereiro de 2026. Esta nova versão conterá as correções de segurança necessárias sem os problemas identificados na leva anterior.

Sinal verde para atualização (Versões 18.3, 17.9 e outras)

O PostgreSQL Global Development Group lançou hoje (26/02/2026) as versões que corrigem os problemas identificados na leva do dia 12/02. Se você adiou sua atualização seguindo nossa recomendação, agora é o momento de planejar o upgrade para as versões 18.3, 17.9, 16.13, 15.17 ou 14.22.

O que foi corrigido nesta “Out-of-Cycle Release”?

• Estabilidade em Standby: Corrigido o erro “could not access status of transaction” que interrompia servidores de réplica.

• Correção no substring(): Resolvida a falha de “sequência de bytes inválida” em textos não-ASCII, que havia sido introduzida na tentativa de correção da CVE anterior.

• Ajuste no pg_trgm: Corrigido um bug na função de similaridade que causava crashes.

• JSON no Postgres 18: As funções json_strip_nulls voltaram a ser imutáveis, permitindo seu uso em índices novamente.

Atenção: Passo extra para usuários da versão 18

Se você já estava rodando qualquer versão do Postgres 18 (18.0, 18.1 ou 18.2), a comunidade recomenda executar um comando SQL manual como superusuário para corrigir a volatilidade das funções de JSON no catálogo, garantindo que seus índices funcionem corretamente.

O sinal verde foi dado! O upgrade não exige pg_upgrade, apenas a substituição dos binários e o reinício do serviço.

A versão 13 do PostgreSQL  de acordo com a política de versões do PostgreSQL, chega ao fim de seu ciclo de suporte, encerrando cinco anos de contribuições e avanços significativos para a comunidade.
Lançada em 24 de setembro de 2020, ela terá seu suporte oficialmente encerrado em 13 de novembro de 2025.

Como acontece a cada nova versão principal, o PostgreSQL 13 trouxe inovações importantes em desempenho, administração e segurança, consolidando ainda mais sua posição como o banco de dados relacional de código aberto mais avançado do mundo.

Com o fim do suporte, é fundamental que administradores e empresas planejem a atualização de suas instâncias, já que a versão 13 deixará de receber correções de bugs e atualizações de segurança.

PostgreSQL 13

O PostgreSQL 13 introduziu melhorias que elevaram tanto o desempenho quanto a administração da plataforma. Houve avanços no sistema de indexação e busca com melhor utilização de espaço e respostas mais rápidas, especialmente em consultas que envolvem agregações ou partições. Também trouxe o VACUUM paralelizado para índices, maior controle de WALs por slot de replicação e aprimoramentos importantes no particionamento, incluindo suporte a replicação lógica, gatilhos BEFORE, além da adição da cláusula WITH TIES.

Esses avanços reforçam a importância de manter o ambiente atualizado para garantir segurança, performance contínua e alinhamento com as evoluções das versões mais recentes do PostgreSQL.

Hora de se despedir, mas só da versão, não do PostgreSQL

Apesar da robustez da versão 13, chega o momento de se despedir dela, principalmente, das vulnerabilidades que essa versão passa a carregar. As melhorias e inovações continuam evoluindo nas versões atuais, e permanecer em uma versão descontinuada representa riscos reais.

É importante lembrar que, quando uma versão não tem mais suporte:

• Não recebe mais patches de segurança
• Novas vulnerabilidades descobertas permanecem abertas
• Falhas críticas deixam de ser corrigidas
• O suporte com ferramentas deixa de existir.

Manter o PostgreSQL atualizado não só garante acesso a novos recursos, mas também oferece a tranquilidade de contar com uma comunidade ativa, que trabalha continuamente para corrigir falhas, fechar brechas de segurança e evoluir o nosso elefante.
Ficar em uma versão sem suporte pode abrir portas para ataques, comprometer a integridade dos dados e gerar impactos significativos e, por vezes, irreversíveis para o negócio.

Atualizar é mais do que acompanhar versões: é proteger seu ambiente, sua empresa e a continuidade das operações.

O que as versões atuais têm de novo?

PostgreSQL 14: Várias melhorias de desempenho: consultas paralelas, workloads altamente concorrentes, partições, replicação lógica, VACUUM mais eficiente.

PostgreSQL 15: Melhorias de desempenho em ordenações (in-memory e on-disk) e outras operações intensivas.

PostgreSQL 16: Replicação lógica a partir de standby (servidores standby podem tornar-se publicadores) e assinantes que aplicam grandes transações em paralelo.

PostgreSQL 17: Novo sistema de gerenciamento de memória para VACUUM, reduzindo consumo de memória e melhorando performance.

PostgreSQL 18: Sub-sistema de I/O assíncrono (AIO) que pode melhorar performance de scans sequenciais, bitmap heap scans, vacuums e outras operações.

As versões atuais do Postgres entregam avanços que crescem a cadeia de desempenho, operação e escalabilidade do banco de dados. Essas melhorias tornam o banco de dados cada vez mais preparado para ambientes modernos, distribuídos e de alta performance.

Atualizar é o caminho

Manter seus sistemas atualizados é uma prática essencial para garantir continuidade operacional, segurança e conformidade. Em um mercado altamente dinâmico e competitivo, operar com versões desatualizadas significa assumir riscos desnecessários.
Atualizar o PostgreSQL não apenas elimina vulnerabilidades conhecidas, mas também assegura acesso a melhorias de desempenho e estabilidade, refletindo diretamente na eficiência e na resiliência do seu ambiente. Proteger a integridade dos dados é proteger o seu negócio, e a atualização contínua é um dos pilares dessa proteção.

Conte conosco!

Se você está pensando em fazer uma migração de versão, nós podemos te ajudar! Somos especialistas em consultoria Postgres e podemos oferecer todo o suporte necessário para garantir que sua migração seja tranquila e eficaz. Desde a avaliação inicial até o treinamento pós-migração, estamos prontos para apoiar você em cada passo do caminho.

[Quero falar com a Timbira!]