Banco de Dados: Como Escolher Entre PostgreSQL, MySQL e MongoDB

A escolha de banco de dados é uma das mais permanentes que você fará

Trocar de framework de frontend é relativamente fácil. Trocar de banco de dados em uma aplicação com dados em produção é um projeto de semanas ou meses, com alto risco. Por isso, a decisão precisa ser consciente e baseada nos requisitos reais da aplicação.

PostgreSQL: a escolha padrão para a maioria das aplicações

PostgreSQL é o banco de dados relacional open source mais avançado do mundo. Para a maioria dos projetos de 2024–2025, é a escolha default correta.

Pontos fortes:

• ACID completo com as mais fortes garantias de consistência do mercado
• Suporte a JSON nativo (JSONB) com indexação — flexibilidade de NoSQL quando necessário
• Full-text search embutido (sem precisar do Elasticsearch para casos simples)
• Arrays, tipos customizados, extensões (PostGIS para geolocalização, pgvector para IA)
• Excelente performance para joins complexos e queries analíticas
• Particionamento de tabelas nativo
• Logical replication robusta
• Extensions: TimescaleDB (time-series), pgAudit (auditoria), pg_cron (jobs)

Quando usar PostgreSQL:

• Aplicações web com dados estruturados (quase tudo)
• Sistemas transacionais (pedidos, pagamentos, estoque)
• Aplicações que precisam de consistência forte
• Quando há necessidade de queries ad-hoc complexas
• Projetos que podem crescer rapidamente

-- PostgreSQL com JSONB: flexibilidade sem perder índices
CREATE TABLE products (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  name text NOT NULL,
  price numeric(10,2) NOT NULL,
  attributes jsonb,  -- { "color": "azul", "size": "M", "material": "algodão" }
  created_at timestamptz DEFAULT now()
);

-- Índice GIN no JSONB para queries eficientes
CREATE INDEX idx_products_attributes ON products USING GIN (attributes);

-- Query: buscar produtos com cor azul
SELECT * FROM products WHERE attributes @> '{"color": "azul"}';

MySQL: sólido, ubíquo, bem suportado

MySQL tem décadas de adoção e um ecossistema imenso. É a primeira escolha de muitos hosts compartilhados e plataformas gerenciadas, e funciona muito bem para aplicações transacionais típicas.

Pontos fortes:

• Maturidade e estabilidade comprovada
• Ferramentas de HA consolidadas (Percona XtraDB Cluster, MySQL InnoDB Cluster)
• Performance excelente para workloads OLTP
• Replicação madura e bem documentada
• Suporte nativo em praticamente todos os serviços gerenciados (RDS, Cloud SQL, etc.)

Pontos fracos em comparação ao PostgreSQL:

• JSON menos capaz (sem índices tão eficientes quanto JSONB)
• Menos extensível (sem o ecossistema de extensions do PostgreSQL)
• Conformidade com SQL ligeiramente menor
• Window functions e CTEs com suporte mais recente

Quando usar MySQL:

• Você já tem expertise em MySQL no time
• Precisa de ferramentas específicas (ex: Percona XtraDB Cluster para HA com Galera)
• Migração de sistema legado que já usa MySQL
• Ambientes WordPress/PHP onde MySQL é o padrão

MongoDB: para dados verdadeiramente não estruturados

MongoDB é um banco de documentos que armazena dados em BSON (JSON binário). Muito popular, mas frequentemente escolhido por razões erradas.

Pontos fortes reais:

• Schema flexível de verdade — diferentes documentos na mesma collection podem ter estruturas radicalmente diferentes
• Escalabilidade horizontal nativa com sharding automático
• Excelente para dados de log, eventos e catálogos com atributos muito variáveis
• Developer experience inicial mais simples (sem schema migrations)
• Bom para documentos aninhados naturais (ex: post de blog com embeds)

Problemas reais do MongoDB:

• Sem transações ACID completas até a versão 4.x (e ainda com limitações)
• Joins são caros (não é o ponto forte do modelo)
• Facilidade inicial vira complexidade depois (sem schema → dados inconsistentes em produção)
• Memória: índices em RAM são menores no PostgreSQL para o mesmo dado

Quando MongoDB faz sentido:

• Catálogos de produtos com centenas de atributos diferentes por categoria
• Sistemas de CMS com tipos de conteúdo muito variáveis
• IoT: ingestão de eventos com estruturas variáveis
• Quando o time já domina e o caso de uso é genuinamente document-oriented

Quando MongoDB É a escolha errada:

• Dados financeiros (use PostgreSQL com ACID)
• Quando você tem relacionamentos fortes entre entidades
• "Porque é mais fácil começar" — dívida técnica de schema inconsistente é real

Comparativo objetivo

| Critério | PostgreSQL | MySQL | MongoDB | |---|---|---|---| | ACID completo | ✅ | ✅ | Parcial | | Performance OLTP | ✅ | ✅ | ✅ | | Joins complexos | ✅ | ✅ | ❌ | | Flexibilidade de schema | ✅ (JSONB) | Parcial | ✅ | | Escalabilidade horizontal | Limitada | Limitada | ✅ (nativo) | | Maturidade de HA | ✅ | ✅ | ✅ | | Full-text search | ✅ (embutido) | Parcial | Parcial | | Extensões / plugins | ✅ (imenso) | Limitado | Moderado | | Conformidade SQL | ✅ | Parcial | N/A |

Regra de ouro

Comece com PostgreSQL. Se você tiver um caso de uso específico que justifique outro banco — volume extremo que exige sharding MongoDB, stack legada em MySQL que não vale migrar, time-series que se beneficia do TimescaleDB — então trocas ou adições fazem sentido.

A proliferação de bancos de dados em um sistema aumenta a complexidade operacional: backup, monitoramento, conhecimento do time, runbooks de incidente. Cada banco adicional deve ter justificativa sólida.