PostgreSQL em produção deixou de ser apenas uma escolha relacional clássica. Com JSONB, pgvector, PostGIS, TimescaleDB, Apache AGE e extensões operacionais como pg_stat_statements e pg_partman, ele pode absorver workloads que antes quase sempre empurravam a arquitetura para vários bancos especializados. A pergunta séria não é se o PostgreSQL consegue. A pergunta é quanto risco e carga operacional faz sentido concentrar nele.

PostgreSQL em produção não é só capacidade

O PostgreSQL continua sendo uma base relacional madura: transações ACID, SQL, integridade referencial e extensibilidade fazem parte da identidade do projeto há muito tempo. O ponto novo, para muita arquitetura moderna, é o quanto essa base passou a atrair workloads vizinhos.

JSONB permite manter dados documentais junto das relações e transações. pgvector coloca embeddings e busca semântica dentro do banco. PostGIS é um caso muito maduro de geoespacial no ecossistema PostgreSQL. TimescaleDB adiciona abstrações para séries temporais. Apache AGE leva consultas de grafo para dentro do mesmo ambiente.

Isso muda a conversa. Em vez de subir um banco documental por causa de algumas tabelas flexíveis, um banco vetorial para a primeira fase de RAG e uma solução geoespacial separada para consultas padrão, o time pode começar com menos peças móveis. Para muita equipe, isso reduz integração, backup, monitoramento, permissões, deploy e plantão.

Mas capacidade não é arquitetura. Uma extensão instalada não elimina o custo de operar o sistema.

O tradeoff de centralizar no PostgreSQL

Centralizar no PostgreSQL pode ser uma decisão excelente quando o workload ainda é moderado, quando o time é pequeno ou quando o custo de operar múltiplos bancos supera o gargalo que eles resolveriam. Nesses cenários, manter ACID cruzando modelos diferentes na mesma query e reduzir infraestrutura separada tem valor real.

O outro lado aparece depois. JSONB com muitos updates pode cobrar em bloat e vacuum. Extensões entram no plano de upgrade, backup, tuning e monitoramento. pg_stat_statements ajuda a medir gargalos, mas também adiciona overhead. pg_partman reduz trabalho recorrente de particionamento, mas não remove cuidado com locks e manutenção em produção pesada.

Polyglot persistence existe por um motivo: alguns workloads realmente se pagam em ferramentas dedicadas. Bilhões de vetores com latência agressiva, telemetria massiva, grafos muito conectados e travessias profundas podem passar do ponto em que concentrar tudo no PostgreSQL ainda é uma simplificação.

O custo real é o blast radius

A decisão pragmática é observar quando a dor da escala supera a dor da integração. Antes disso, adicionar banco especializado pode ser complexidade antecipada. Depois disso, insistir em centralizar pode transformar o PostgreSQL em um ponto de concentração de CPU, I/O, memória, dependências e risco.

O critério não é gosto por uma stack mais simples nem entusiasmo por ferramenta especializada. É volume, latência, modelo de consulta, maturidade do time e blast radius aceitável. Se o banco cai e junto caem relacional, documental, vetorial, temporal, geoespacial e grafo, a arquitetura ficou mais simples no desenho, mas talvez mais frágil na operação.

PostgreSQL ficou grande, e isso é uma vantagem técnica importante. Só não muda a regra central: toda arquitetura cobra tradeoff. A maturidade está em decidir onde a complexidade deve morar, não em fingir que ela desapareceu.

Referências

• About PostgreSQL - PostgreSQL Global Development Group - https://www.postgresql.org/about/
• Sharding Postgres at Notion - Notion Engineering - https://www.notion.so/blog/sharding-postgres-at-notion
• JSON Types - PostgreSQL Documentation - https://www.postgresql.org/docs/current/datatype-json.html
• pgvector - pgvector project - https://github.com/pgvector/pgvector
• TimescaleDB Documentation - Timescale - https://docs.timescale.com/
• PostGIS - PostGIS project - https://postgis.net/
• Apache AGE - Apache Software Foundation - https://age.apache.org/
• pg_stat_statements - PostgreSQL Documentation - https://www.postgresql.org/docs/current/pgstatstatements.html
• pg_partman - pg_partman project - https://github.com/pgpartman/pg_partman
• Polyglot Persistence - Martin Fowler - https://martinfowler.com/bliki/PolyglotPersistence.html