Em 2026, use Postgres — até onde o requisito deixar

Pense no seu banco de dados como uma casa. Sala, quarto, cozinha, garagem — cada cômodo tem uma função, mas todos vivem debaixo do mesmo teto. Você não constrói um restaurante do outro lado da cidade só porque precisa preparar o jantar. Nem aluga uma garagem comercial pra guardar o carro.

Postgres funciona assim. Busca, vetores, time-series, filas, documentos — cômodos diferentes, uma casa só. Mesmo telhado, mesma fundação, mesma chave.

Esse argumento não é meu — é a tese do post "It's 2026, Just Use Postgres" publicado pela equipe do Tiger Data (criadores do TimescaleDB) no HackerNoon. Vale ler na íntegra, mas aqui está minha leitura do porquê a tese virou ainda mais forte com a chegada dos agentes.

A armadilha da "ferramenta certa pra cada tarefa"

A indústria de banco de dados vende um clichê: "use a ferramenta certa pra cada job". Soa sábio. Também vende muito banco.

Você segue o conselho e termina com:

Elasticsearch para busca
Pinecone para vetores
Redis para cache
MongoDB para documentos
Kafka para filas
InfluxDB para time-series
Postgres pro que sobrou

Parabéns: sete bancos para operar. Sete linguagens de query, sete estratégias de backup, sete modelos de segurança, sete dashboards de monitoramento — e sete coisas que podem quebrar às 3 da manhã.

Quando algo quebra de verdade? Boa sorte subindo um ambiente de teste com snapshots sincronizados nos sete sistemas, no mesmo ponto no tempo, todos rodando no seu laptop.

A era da IA mudou a conta

O argumento "consolide tudo no Postgres" não é novo. O que mudou em 2026 é quem está pedindo o banco: agentes de IA.

Pense no que um agente precisa fazer pra resolver um bug em produção:

Subir um banco de teste com dados parecidos com produção.
Tentar um fix.
Verificar.
Derrubar tudo.

Com um banco só, isso é um fork e pronto.

Com sete, o agente precisa coordenar snapshots em cada sistema, subir sete serviços, configurar sete connection strings, torcer pra nada divergir durante o teste, e depois desmontar tudo. Não é uma inconveniência — é um projeto de pesquisa.

Não por acaso, a maioria dos agentes de coding hoje assume implicitamente arquitetura de banco único. E isso vale também pro engenheiro de plantão que precisa reproduzir um incidente, pra qualquer CI que quer dados realistas, e pro time que quer experimentar sem medo.

Consolidação de banco era uma preferência arquitetural. Na era dos agentes, está virando requisito funcional.

O segredo: os algoritmos são os mesmos

O que os fornecedores especializados não querem que você pense muito:

Você precisa de...	Ferramenta especializada	Extensão Postgres	Mesmo algoritmo
Full-text search	Elasticsearch	`pg_textsearch`	BM25
Vector search	Pinecone	`pgvectorscale`	HNSW / DiskANN
Time-series	InfluxDB	`TimescaleDB`	Particionamento temporal
Documentos	MongoDB	`JSONB`	Indexação de documento
Cache	Redis	`UNLOGGED tables`	In-memory
Filas	Kafka	`pgmq`	Message queuing
Geo	GIS especializado	`PostGIS`	Padrão da indústria desde 2001

E não é teórico:

pgvectorscale entrega 28x menos latência p95 e 16x mais throughput que o Pinecone em benchmark de 50M vetores a 99% de recall.
TimescaleDB empata ou bate o InfluxDB em workloads de séries temporais — com SQL, JOINs e ACID.
pg_textsearch roda o mesmo BM25 que ranqueia no Elasticsearch.

Postgres extensions não são experimentos. PostGIS está em produção desde 2001. TimescaleDB desde 2017. pgvector desde 2021. Mais de 48.000 empresas rodam Postgres — incluindo Netflix, Spotify, Uber e Discord.

Quando o especialista ainda compensa

A leitura honesta: existe uma fatia pequena de casos onde a ferramenta especializada ainda vence. A coluna "quando você ainda precisa do especialista" do post original é o que importa:

Kibana + agregações aninhadas complexas + busca em petabytes → Elasticsearch.
Sharding multi-tenant gerenciado em bilhões de vetores → Pinecone.
Ambiente puramente métrico, sem dado relacional → InfluxDB.
Modelo totalmente schemaless + ecossistema de change streams → MongoDB.
Pub/sub, sorted sets, scripting em Lua, latência sub-ms em estrutura complexa → Redis.
Streaming de eventos cross-datacenter com consumer groups → Kafka.

São requisitos que você sente porque bateu numa parede concreta — não porque algum marketing avisou pra "planejar pro futuro".

Os custos que ninguém soma

Mesmo que um banco especializado vença em um benchmark específico, você paga em todas as outras dimensões:

Carga cognitiva. Seu time precisa saber SQL + comandos do Redis + Query DSL do Elasticsearch + pipelines do Mongo + padrões do Kafka + linguagem do Influx. Isso não é especialização, é fragmentação.

Consistência. Manter Elasticsearch em sincronia com Postgres significa construir jobs de sincronização. Eles falham silenciosamente. Dados divergem. Você adiciona reconciliação. A reconciliação também falha. Aí seu time está mantendo encanamento de dados em vez de construir o produto que a empresa vende.

Matemática de SLA. Três sistemas a 99,9% combinam para 99,7%. Isso são 26 horas de downtime por ano, não 8,7. Cada sistema novo multiplica a superfície de falha.

Custo real. Plexigrid consolidou de quatro bancos para um e ganhou 350x em performance de query. Flogistix cortou 66% do custo. Latitude economizou US$ 12 mil/mês só de compressão.

Onde o Postgres brilha de verdade

Antes de falar dos limites, vale fixar onde ele é a escolha obviamente certa — algo bem destilado neste vídeo sobre os limites do Postgres em sistemas distribuídos:

Monolitos e apps de pequeno/médio porte — o clássico "sisteminha de padaria, farmácia ou mercadinho". Um ambiente, um banco, zero complexidade de múltiplos nós. É a esmagadora maioria dos sistemas reais.
Nó único (single node) — quando app e banco vivem no mesmo servidor (ou poucos), e não há necessidade de sharding, Postgres voa.
Consistência + dados estruturados (CA) — no CAP, ser CA é uma vantagem quando você não precisa de tolerância a partição. Você ganha relacionamentos sólidos, transações ACID e consistência forte sem pagar o imposto do distribuído.
Mais leitura que escrita — a evolução natural via read replicas (master pra escrita + réplicas pra leitura) resolve gargalo inicial de forma simples, com ORMs comuns, sem reescrever a arquitetura.
Projetos iniciais e familiaridade — é o relacional default que quase todo dev conhece. Simples de subir, atende a maioria das necessidades de quem está começando a escalar.

Em uma frase: Postgres brilha quando escala global e partição de rede não são o seu problema — que é a realidade de quase todo produto antes de virar um Uber ou um Nubank.

O outro lado: onde Postgres encosta na parede

Consolidar em Postgres é a aposta certa pra a maioria dos sistemas — monolitos e apps de pequeno/médio porte. Mas seria desonesto parar aqui sem falar do limite real: Postgres nasceu como banco de nó único (single node), e isso aparece quando o sistema precisa ser genuinamente distribuído em larga escala.

1. Teorema CAP — falta tolerância a partição. No CAP, Postgres é um banco CA (Consistência + Disponibilidade): não foi construído pra garantir tolerância a partições de rede (P). Como todo sistema distribuído precisa lidar com partições, Postgres não é a escolha natural quando a topologia é multi-nó por design.

2. Gargalo de escrita (master-replica). O caminho padrão pra escalar é read replicas: um master absorve as escritas, várias réplicas servem leitura. Funciona muito bem pra leitura pesada — mas o master continua sendo o único ponto de escrita. Sob alta volumetria de writes, ele vira o gargalo.

3. Sharding é manual e doloroso. Bancos como Cassandra fazem sharding (fragmentação de dados entre nós) de forma automática e nativa. Em Postgres, distribuir dados entre fragmentos é um trabalho manual e complexo — você acaba escrevendo lógica de roteamento pra saber em qual nó cada dado mora. Extensões como Citus ajudam, mas é uma camada a mais, não um comportamento nativo.

4. O trade-off de replicação é cruel.

Síncrona → garante consistência, mas se a rede particiona, o banco não confirma a escrita em todos os nós e sua aplicação fica indisponível.
Assíncrona → melhora performance, mas abre consistência eventual: um usuário pode ler dado desatualizado logo após um update. Inaceitável em domínios como o bancário.

5. Custo. Forçar Postgres a operar distribuído em larga escala (ex.: RDS multi-AZ na AWS, instâncias gordas) pode custar caro — às vezes mais caro que um banco que já nasceu distribuído.

Bancos como Cassandra (quórum) ou MongoDB (Raft pra eleição/replicação) trazem esses mecanismos no núcleo. Postgres não — e adaptá-lo cobra um preço técnico e financeiro desproporcional quando você realmente está nesse regime.

A questão é honesta: você está mesmo nesse regime? A maioria não está. "Larga escala distribuída" costuma ser uma profecia de arquitetura que nunca se cumpre — e o custo de prepará-la cedo demais é exatamente a fragmentação que este post critica. Mas se você opera escrita global, multi-região com partição garantida, ou consistência sob falha de rede como requisito hard — aí o single node do Postgres é uma parede de verdade, não marketing.

E quando é banco/fintech? O que usar

Em aplicação bancária e financeira, a prioridade não é negociável: consistência forte. Todo nó precisa ver o dado mais atual. Consistência eventual aqui é defeito, não trade-off — basta imaginar transferências repetidas disparadas sobre um saldo desatualizado. Quando o regime é distribuído e crítico, estes são os candidatos:

CockroachDB — relacional distribuído, fala o protocolo do Postgres e usa Raft internamente pra garantir consistência forte em escala. É o substituto natural pra quem ama Postgres mas precisa de distribuição real.
Google Spanner — o "monstro" da categoria: relógios atômicos + TrueTime entregam consistência externa em escala global, resolvendo concorrência no nível do microssegundo. Caro e acoplado ao GCP, mas sem rival quando o requisito é esse.
MongoDB — frequentemente lembrado só por performance, mas no PACELC ele é PC/EC (prioriza consistência tanto em partição quanto em operação normal) e oferece transações ACID. Viável pra dado financeiro quando bem configurado.
Cassandra com quórum — por essência é AP/EL (disponibilidade e baixa latência), mas é versátil: definindo o nível de consistência como QUORUM ou ALL em tempo de query, você força a maioria/todos os nós a confirmarem antes de responder — o suficiente pra cenários críticos.

Note o que não está nessa lista por padrão: Postgres. Não por ser ruim — pelo oposto do que defende este post. É um single node excelente; só não tem tolerância a partição nativa nem sharding automático pra sustentar um core bancário distribuído e global sem trabalho manual caro. Pra fintech de pequeno/médio porte, monolito ou banco regional, Postgres segue ótimo. Pra core transacional planetário, escolha uma ferramenta que nasceu pra isso.

Antes de tudo: sem requisito não tem arquitetura

Repare que cada decisão acima — Postgres consolidado, distribuído, core bancário — não vem da moda nem do hype do banco da vez. Vem de requisito.

Sem requisitos, não tem arquitetura.

É a única regra que precede todas as outras. "CA ou AP?" não é uma preferência estética — é uma resposta a "eu preciso tolerar partição de rede?". "Postgres ou CockroachDB?" responde a "eu tenho escrita global multi-região?". "Um banco ou sete?" responde a "qual problema eu realmente tenho hoje?".

Quem escolhe banco antes de levantar requisito está chutando — e chute caro, porque arquitetura erra pra cima (complexidade que você carrega pra sempre) ou pra baixo (parede que te derruba em produção). O pecado mais comum, e o que este post combate, é arquitetar para um requisito imaginário do futuro.

A regra prática

Comece com um banco. Adicione complexidade só quando você provou que precisa dela.

Postgres + extensões corretas resolve busca, vetores, time-series, documentos, cache, filas, geo e jobs agendados. Os algoritmos batem com os especializados. As extensões são battle-tested. E a simplicidade operacional compõe a cada mês que você não adiciona mais um sistema.

A maioria dos times adota um banco especializado antes de testar se Postgres dá conta. Adiciona Elasticsearch porque "é o que se usa pra busca", não porque testou pg_textsearch e achou pouco. Adiciona Redis porque "todo mundo usa Redis pra cache", não porque UNLOGGED tables não aguentaram a carga.

O conselho da "ferramenta certa" soa sábio. Mas com frequência, é a solução para um problema que você ainda não tem — vendida por quem lucra com você tendo.

Teste a suposição primeiro. Depois decida.

TL;DR: Em 2026, "boring tech" venceu — e Postgres está no centro. Antes de adicionar mais um banco à sua stack, leia o post original do Tiger Data e teste se uma extensão resolve. Seu time, seus agentes e o engenheiro de plantão agradecem.