Postgres vs MongoDB em 2026: Quando Usar Cada Um

Em 2026, a discussão entre PostgreSQL e MongoDB ficou menos sobre "SQL versus NoSQL" e mais sobre "qual ferramenta resolve o meu problema específico com o menor custo operacional". Depois de anos de evolução, os dois chegaram a um ponto curioso: o Postgres virou o banco "default" para a maioria dos casos, ganhando recursos de documentos, busca vetorial, full-text nativo e replicação lógica que cobrem boa parte do que só o Mongo entregava. Do outro lado, o MongoDB amadureceu operacionalmente, com transações multi-documento estáveis, time series collections, queryable encryption e uma plataforma gerenciada (Atlas) cada vez mais opinativa. A escolha hoje depende do seu modelo de dados, da sua operação e de quanto você está disposto a pagar por conveniência.

Em 2025 migrei um sistema de catálogo de produtos de MongoDB para PostgreSQL com JSONB numa operação que durou cerca de oito semanas. Eram 47 milhões de documentos com estruturas heterogêneas (alguns SKUs tinham 12 atributos, outros passavam de 80), divididos em três coleções principais. Movi tudo para três tabelas Postgres com colunas relacionais para os campos sempre presentes (sku, price, stock, category_id) e uma coluna attributes jsonb para o resto, com índices GIN nas chaves mais consultadas. Resultado: a latência p95 das leituras pesadas caiu de 180ms para 42ms, o custo do cluster caiu 38% (saí de um M40 Atlas para uma instância db.r6g.large no RDS), e eu parei de precisar sincronizar dados com um Elasticsearch separado porque o tsvector do Postgres deu conta da busca. A lição foi dupla: (1) o Postgres é bom em modelar "o que você sabe" como colunas e "o que você não sabe" como JSONB; (2) se o seu schema é genuinamente imprevisível e muda toda semana, essa migração vira fricção desnecessária.

O que mudou entre Postgres e MongoDB em 2026

Nos últimos dois anos, o Postgres consolidou três frentes que antes empurravam equipes para o Mongo. A primeira é o suporte maduro a documentos via JSONB, agora com operadores de path (@?, @@) e índices parciais que tornam queries em campos aninhados competitivas. A segunda é a ascensão do pgvector, que colocou o Postgres no centro do boom de RAG e busca semântica sem precisar de um banco vetorial à parte. A terceira é a replicação lógica ficando realmente confiável para migrações zero-downtime e CDC.

Já o MongoDB respondeu com melhorias em transações, consultas federadas entre Atlas e S3, Atlas Search (baseado em Lucene) e Atlas Vector Search. Em 2026, o Mongo é uma plataforma de dados, não apenas um banco de documentos: a proposta é ter OLTP, busca, vetor e analytics num só lugar. O trade-off é óbvio: você paga por essa integração e fica mais colado ao Atlas.

Pontos fortes do PostgreSQL

O Postgres brilha quando os seus dados têm relações reais e você precisa de garantias fortes. Joins entre dez tabelas continuam sendo o habitat natural dele; o planner sabe reordenar, paralelizar e usar índices parciais de forma que nenhum banco de documentos consegue replicar sem você codar no app. A combinação de MVCC, transações ACID verdadeiras e constraints declarativas (CHECK, EXCLUDE, FOREIGN KEY) transforma o banco num guardião da integridade, o que reduz bugs no domínio.

Além disso, o ecossistema de extensões é imbatível: pgvector para embeddings, PostGIS para geoespacial, TimescaleDB para séries temporais, pg_partman para particionamento gerenciado, pg_cron para jobs, pg_stat_statements para profiling. Na prática, isso significa que você raramente precisa sair do Postgres para resolver um problema adjacente. Para times pequenos, isso é ouro: menos sistemas, menos pipelines, menos pontos de falha.

Pontos fortes do MongoDB

O Mongo é imbatível quando o seu modelo de dados é genuinamente hierárquico e mutável. Se você está escrevendo um CMS headless, um event store, um agregador de logs estruturados ou um motor de configuração, salvar o documento inteiro de uma vez, sem joins, é mais simples. O aggregation framework do Atlas é poderoso para pipelines de transformação e costuma ser mais ergonômico do que CTEs recursivos para certos problemas de árvore.

Sharding nativo continua sendo o ponto em que o Mongo ganha por goleada. Escalar horizontalmente no Postgres exige Citus, Aurora Limitless, ou você mesmo construir um esquema de partição com roteamento no app. No Mongo, você define uma shard key e o balanceador cuida do resto. Change streams são outro recurso que não tem equivalente trivial: consumir um "log de mudanças" direto do banco para alimentar websockets, caches ou webhooks é nativo.

Performance comparada: o que a prática mostra

Benchmarks sintéticos mentem. O que a operação mostra em 2026 é:

• Escrita de documentos grandes e auto-contidos: Mongo costuma ser 15-30% mais rápido em inserts puros quando não há índices secundários pesados.
• Leituras com joins e agregação relacional: Postgres domina, especialmente com parallel seq scan e hash joins.
• Busca full-text: Postgres com tsvector é excelente até poucas dezenas de milhões de documentos; acima disso, Atlas Search (Lucene) ou um Elasticsearch externo entregam ranking mais sofisticado.
• Busca vetorial: pgvector com HNSW chegou perto de soluções dedicadas para datasets até 10M de vetores. Acima disso, ainda vale considerar Pinecone, Qdrant ou Atlas Vector Search.
• Analytics ad-hoc: nenhum dos dois é ideal; considere exportar para ClickHouse, DuckDB ou um data warehouse.

Operação e custo: Atlas, Supabase, RDS, Neon

Custo total de posse é onde a decisão frequentemente se define. O MongoDB Atlas é uma plataforma muito completa, mas cara; você paga por instância dedicada, backups, Atlas Search, Vector Search, Data Federation, e o preço sobe rápido quando o cluster cresce. Em compensação, você recebe observabilidade, alertas, performance advisor, serverless, multi-region e integração com Kafka quase sem esforço.

No Postgres, a disputa de providers é saudável: Supabase entrega Postgres + Auth + Storage + Realtime + Edge Functions num pacote de DX muito polido para startups, Neon tem branching de banco (ótimo para preview environments), Aurora Postgres-Compatible escala melhor em workloads sérios na AWS, e o RDS clássico continua sendo o cavalo de batalha. A soma "Supabase + pgvector + tsvector + Edge Functions" substitui, para a maioria dos projetos, um stack que antes envolvia Mongo + Elasticsearch + Redis + um backend custom.

Quando escolher cada um

Escolha PostgreSQL quando: o domínio tem relações claras; você precisa de transações fortes; quer busca full-text e vetorial sem orquestrar serviços extras; o time já sabe SQL; você está construindo um SaaS multi-tenant; ou quando "um banco para tudo" é uma vantagem estratégica. Em 2026, o Postgres é a escolha default para 80% dos novos projetos backend.

Escolha MongoDB quando: o modelo é genuinamente hierárquico e cada registro é auto-suficiente; você precisa de sharding nativo desde o dia um; change streams são um requisito de produto; a equipe já é fluente em Mongo; ou quando você quer usar Atlas como plataforma unificada de dados e aceita o lock-in em troca de velocidade de entrega. Casos típicos: catálogos altamente variáveis, event sourcing, IoT, telemetria, CMS headless, agregação de dados de terceiros.

Evite os extremos ideológicos. "Usar Mongo porque SQL é chato" é tão ruim quanto "usar Postgres porque NoSQL é moda passageira". Ambos são bancos sérios, em produção há mais de uma década, e escolher errado custa caro na migração.

Conclusão

Em 2026, o Postgres se consolidou como a escolha default por uma razão simples: ele absorveu quase tudo que antes justificava o Mongo, sem perder o que sempre o diferenciou. O MongoDB ainda é a resposta certa quando o seu modelo de dados é fundamentalmente um documento, quando você precisa de sharding nativo e quando Atlas como plataforma unificada vale o preço. Na maioria dos outros casos, comece com Postgres, use JSONB onde fizer sentido, adicione pgvector quando precisar de embeddings e só migre para outro sistema quando um gargalo real aparecer. A pior decisão é escolher por moda ou por PR de benchmark; a melhor é escolher pelo formato dos seus dados, pela maturidade do seu time e pela operação que você consegue sustentar.