PostgreSQL vs. MongoDB vs. MySQL: guia definitivo para escolher em 2026

A pergunta "qual banco é melhor?" está errada. A pergunta correta é "qual banco é melhor para este modelo de dados, este volume e esta equipe?"

Cada banco foi otimizado para cenários específicos. Usar MongoDB como se fosse relacional (com joins manuais na aplicação) é doloroso. Usar PostgreSQL para dados hierárquicos altamente variáveis é possível, mas trabalhoso.

Os três erros mais comuns na escolha:

1. Escolher por hype: "MongoDB é NoSQL, NoSQL é moderno, vou usar MongoDB". NoSQL não é sinônimo de moderno — é uma ferramenta para problemas específicos.
2. Escolher pelo que a big tech usa: Facebook usa Cassandra para dados de 3 bilhões de usuários. Você tem 3.000 usuários. O contexto é completamente diferente.
3. Não escolher (usar qualquer um): "Banco é banco, tanto faz". Essa decisão vai custar 6 meses de migração dolorosa quando bater em algum limite.

Este guia te dá os critérios para fazer a escolha certa — com dados, não opinião.

PostgreSQL é o banco relacional open-source mais avançado disponível. Em 2026, acumula funcionalidades que antes existiam apenas em bancos enterprise caros (Oracle, SQL Server) — sem custo de licença.

Core features que definem PostgreSQL

• ACID completo: Transações robustas com isolation levels configuráveis (Read Committed até Serializable). Sem perda de dados, sem inconsistências.
• JSON nativo (jsonb): Coluna jsonb com indexação GIN permite armazenar e consultar dados semiestruturados com performance excelente. Em muitos casos, elimina a necessidade de MongoDB.
• Full-text search: Busca textual com ranking nativo (ts_vector, ts_query). Para volumes até ~5M de documentos, elimina Elasticsearch.
• pgvector: Busca vetorial (embeddings de IA) direto no banco — até ~5M vetores com performance aceitável. Sem precisar de Pinecone ou Weaviate.
• Row-level security (RLS): Políticas de acesso a nível de linha, nativas. Ideal para multi-tenancy: cada tenant vê apenas seus dados sem lógica extra na aplicação.
• Extensões poderosas: PostGIS (geoespacial, padrão da indústria), TimescaleDB (séries temporais), pgcrypto (criptografia), pg_stat_statements (análise de queries).
• Particionamento nativo: Tabelas com bilhões de registros divididas automaticamente por data, região ou qualquer critério.
• Logical replication: Réplicas de leitura sem downtime, CDC (Change Data Capture) para streaming de eventos.

Performance do PostgreSQL em 2026

Quando PostgreSQL NÃO é suficiente

• Escrita com throughput absurdo: >100k writes/seg sem batch — considere Cassandra, ScyllaDB ou TimescaleDB.
• Clustering horizontal automático: PostgreSQL escala verticalmente muito bem e horizontalmente com read replicas, mas não tem sharding automático nativo como MongoDB ou CockroachDB.
• Dados efêmeros de altíssimo volume: Logs de acesso com 100M+ registros/dia — considere ClickHouse ou banco de séries temporais.

MongoDB é frequentemente mal utilizado — ora como substituto do relacional (péssima ideia), ora como "banco para startups" sem critério técnico. Quando usado para o que foi projetado, é excelente.

Core features que definem MongoDB

• Schema flexível: Cada documento pode ter estrutura diferente na mesma collection. Ideal para catálogos onde cada produto tem atributos únicos.
• Sharding automático: Distribuição horizontal de dados entre nós. Configuração simples comparada ao PostgreSQL Citus.
• Atlas (gerenciado): Experiência de developer experience excelente — deploy em 3 cliques com monitoramento, backup e alertas incluídos.
• Aggregation Pipeline: Framework de processamento de dados potente, similar a SQL com GROUP BY/HAVING mas mais expressivo para dados hierárquicos.
• Change Streams: Reatividade nativa — aplicações podem escutar mudanças em tempo real (similar a CDC do PostgreSQL).
• Atlas Search: Full-text search integrado (baseado em Apache Lucene), eliminando necessidade de Elasticsearch em ecossistema MongoDB.

Quando MongoDB brilha

Quando MongoDB é a escolha errada

• Dados fortemente relacionados: Pedidos com itens, pagamentos, clientes, endereços — tudo interligado. JOINs no MongoDB ($lookup) são lentos e verbosos. Use relacional.
• Transações multi-documento frequentes: MongoDB tem transações multi-documento desde v4.0, mas são significativamente mais lentas que em bancos relacionais. Se >30% das operações são transacionais, relacional é melhor.
• Relatórios e analytics: Aggregation Pipeline é potente mas a sintaxe é complexa. SQL é mais legível para queries analíticas e possui ecossistema BI muito mais maduro.
• "Banco para startups": A ausência de schema validation não elimina a necessidade de modelagem. Apenas transfere a validação do banco para a aplicação — onde é mais frágil.

MySQL ainda é o banco mais instalado do mundo — herdado de décadas de stacks LAMP (Linux, Apache, MySQL, PHP). Em 2026, perdeu terreno significativo para PostgreSQL em novos projetos, mas mantém relevância em cenários específicos.

O que MySQL faz bem

• Hospedagem compartilhada: Praticamente todos os planos de hosting (cPanel, Plesk) incluem MySQL. PostgreSQL é mais raro nesses ambientes.
• Stacks WordPress/Drupal/PHP: Mudar de MySQL é risco sem benefício claro quando a aplicação é um CMS estável.
• Read-heavy workloads com InnoDB: Performance excelente em leituras simples com o storage engine InnoDB.
• Replicação master-slave madura: Configuração simples e estável para read replicas.
• Familiaridade da equipe: Se a equipe tem 10 anos de MySQL e o projeto dura 6 meses, mudar de banco não compensa.

Por que NÃO escolher MySQL para projetos novos

Resumo: PostgreSQL tem tudo que MySQL tem, mais funcionalidades enterprise, melhor conformidade SQL, e ecossistema de extensões mais rico. Para projetos novos sem restrição de hosting, PostgreSQL é a escolha superior.

Leitura do comparativo

• Se precisa de JOINs e transações: PostgreSQL > MySQL > MongoDB.
• Se precisa de escrita massiva: MongoDB > PostgreSQL > MySQL.
• Se precisa de schema flexível: MongoDB > PostgreSQL (jsonb) > MySQL.
• Se precisa de ecossistema BI: PostgreSQL > MySQL > MongoDB.
• Se precisa escalar horizontalmente: MongoDB > PostgreSQL (com Citus) > MySQL (com Vitess).
• Se precisa de busca vetorial/IA: PostgreSQL (pgvector) ≈ MongoDB (Atlas Vector) > MySQL.

Use este fluxograma para chegar à resposta em 3 perguntas:

Pergunta 1: Os dados são fortemente relacionados?

Sim (pedidos → itens → pagamentos → clientes → endereços): banco relacional (PostgreSQL ou MySQL). Siga para a pergunta 2.

Não (cada documento é independente, poucos relacionamentos, estrutura variável): considere MongoDB. Siga para a pergunta 3.

Pergunta 2 (relacional): Tem restrição de hosting ou stack LAMP?

Sim (hosting compartilhado, WordPress, equipe só sabe MySQL): MySQL.

Não: PostgreSQL. Sem exceção.

Pergunta 3 (documento): >30% das operações são transacionais?

Sim: Reconsidere. PostgreSQL com jsonb pode ser melhor que MongoDB com transações pesadas.

Não: MongoDB. Ideal para dados de documento com escrita intensiva e schema variável.

Cenário por tipo de projeto

Custo mensal por volume (serviço gerenciado em cloud)

Custos ocultos

• MongoDB Atlas egress: Transferência de dados para fora do Atlas é cobrada (~R$ 0,50/GB acima do free tier). Se sua API faz muitas queries, o egress pode superar o custo do cluster.
• MongoDB licença SSPL: Se você vende banco como serviço (DBaaS), a licença SSPL do MongoDB pode ser um problema legal. PostgreSQL e MySQL não têm essa restrição.
• Expertise da equipe: MongoDB exige conhecimento de modelagem de documentos — que é fundamentalmente diferente de modelagem relacional. Equipe relacional usando MongoDB gera modelagem pobre (e problemas de performance).
• Custo de migração futura: Migrar de MongoDB para PostgreSQL custa 3-6 meses de engenharia. Migrar de MySQL para PostgreSQL custa 2-4 semanas (schemas similares). Escolher errado tem custo real.

Self-hosted vs. gerenciado

Recomendação: Use gerenciado para times com <3 engenheiros de infra. O custo adicional de ~30% do serviço gerenciado é muito menor que o custo de um DBA administrando backup, replicação, failover, monitoring e updates de segurança.

Self-hosted faz sentido quando: compliance exige dados on-premises, volume é tão alto que o custo gerenciado fica proibitivo (>R$ 10k/mês), ou quando há equipe de infra dedicada.

Quando migrar

• MySQL → PostgreSQL: Quando precisa de jsonb, pgvector, PostGIS, RLS, ou conformidade SQL avançada. Migração relativamente simples (schemas similares). Custo: 2-4 semanas de engenharia.
• MongoDB → PostgreSQL: Quando o modelo de dados se tornou fortemente relacional (muitos $lookups) e transações são frequentes. Migração complexa (redesign do schema). Custo: 3-6 meses de engenharia.
• PostgreSQL → MongoDB: Raro. Se o modelo de dados se tornou predominantemente documental e escrita é o gargalo. Avalie antes pgvector + jsonb.

Estratégia de migração: Strangler Fig

1. Dual write: Novas operações escrevem nos dois bancos simultaneamente
2. Migração de dados históricos: ETL para transferir dados existentes em lotes
3. Validação: Compare resultados de queries nos dois bancos durante 2-4 semanas
4. Cutover: Mude a leitura para o novo banco
5. Cleanup: Remova o dual write e descomissione o banco antigo

Ferramentas de migração

Sistemas modernos não usam um único banco para tudo. A combinação certa reduz custos, melhora performance e simplifica cada componente.

Combinação clássica (cobre 90% dos projetos)

Combinação avançada (projetos com IA ou analytics)

Anti-padrões de multi-banco

• PostgreSQL como cache: Fazer SELECT frequente em tabela sem índice para "verificar" dados que poderiam estar no Redis. Banco relacional não é cache.
• MongoDB como fila: Collections com "status: pendente" para processar tarefas. Use Redis, SQS ou RabbitMQ.
• Duplicação desnecessária: Manter os mesmos dados no PostgreSQL e no MongoDB "por segurança". Escolha um como SSOT e replique com propósito (analytics, busca).
• Micro-bancos por microserviço: Cada microserviço com seu banco é a teoria. Na prática, para equipes com <10 devs, um banco PostgreSQL com schemas separados é mais simples e igualmente eficaz.

Se você leu este guia inteiro e ainda não tem certeza: use PostgreSQL. Ele resolve 80% dos problemas de banco de dados, tem o ecossistema mais completo de extensões, a maior comunidade e a melhor empregabilidade para quem aprende SQL.

Resumo em 5 regras

1. Novo projeto sem restrições? PostgreSQL.
2. Dados hierárquicos, variáveis, escrita intensiva? MongoDB.
3. Stack PHP/WordPress em hosting compartilhado? MySQL.
4. Precisa de cache, sessões ou filas? Adicione Redis — não abuse do banco principal.
5. Precisa de busca vetorial para IA? pgvector (se PostgreSQL) ou Atlas Vector Search (se MongoDB).

O banco de dados é a fundação do sistema. Errar aqui gera meses de migração dolorosa. Acertar aqui gera anos de produtividade. Invista 1-2 dias na decisão — vale mais do que semanas de refatoração depois.