PostgreSQL vs MySQL vs MongoDB em 2026: A Comparação Honesta que Ninguém Pediu

A cada poucos meses, o mesmo debate ressurge no Reddit, Hacker News e no Slack do seu time: "Qual banco de dados usar?" E toda vez, as respostas vão desde "só usa Postgres pra tudo" até memes de "MongoDB is web scale" de 2012.

A verdade que ninguém quer admitir: não existe um banco de dados universalmente "melhor". Mas SIM existem escolhas certas e erradas pra situações específicas. Este guia vai te ajudar a tomar essa decisão com dados reais, não lealdade tribal.

Bora resolver isso de uma vez—ou pelo menos até 2027.

Resposta rápida (TL;DR)

Antes de mergulhar, aqui está a matriz de decisão que a maioria dos times deveria seguir:

Agora vamos entender por que essas recomendações existem.

PostgreSQL: O Canivete Suíço

PostgreSQL virou a recomendação padrão em 2026, e por boas razões. Não é porque tá na moda—é porque genuinamente faz quase tudo bem.

O que PostgreSQL faz bem

1. ACID Que Realmente Funciona

A implementação MVCC do PostgreSQL é testada em batalha:

-- PostgreSQL lida com isso corretamente, sempre
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

Você nunca vai ver atualizações parciais ou leituras fantasma com tratamento correto de transações.

2. Tipos de Dados Avançados

-- JSON com indexação de verdade
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    data JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_events_data ON events USING GIN (data);

-- Query JSON como se fosse NoSQL
SELECT * FROM events 
WHERE data @> '{"type": "purchase", "amount": {"$gt": 100}}';

-- Arrays como cidadãos de primeira classe
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT,
    tags TEXT[],
    preferences JSONB
);

SELECT * FROM users WHERE 'premium' = ANY(tags);

-- Busca full-text sem Elasticsearch
SELECT * FROM articles 
WHERE to_tsvector('portuguese', title || ' ' || body) 
      @@ to_tsquery('portuguese', 'database & performance');

3. Ecossistema de Extensões

O sistema de extensões do PostgreSQL não tem rival:

• PostGIS: Suporte geoespacial completo (usado por OpenStreetMap, Uber)
• TimescaleDB: Dados de séries temporais em escala
• pgvector: Embeddings vetoriais pra AI/ML
• Citus: Sharding horizontal pra escala massiva

-- Exemplo: Busca de similaridade vetorial pra IA
CREATE EXTENSION vector;

CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(1536)  -- Dimensões de embedding do OpenAI
);

-- Encontrar documentos similares
SELECT * FROM documents 
ORDER BY embedding <-> '[0.1, 0.2, ...]'  -- Seu vetor de consulta
LIMIT 10;

Onde PostgreSQL deixa a desejar

• Complexidade de replicação: Precisa de mais expertise que MySQL
• Uso de recursos: Usa mais memória pra cargas simples
• Hosting compartilhado: Menos comum em planos baratos

MySQL: O Cavalo de Batalha Confiável

MySQL alimenta mais websites que qualquer outro banco. WordPress, Drupal, Joomla e inúmeras apps customizadas dependem dele.

O que MySQL faz bem

1. Performance de Leitura

-- MySQL manda bem em leituras simples de alto volume
SELECT id, title, created_at 
FROM posts 
WHERE status = 'published' 
ORDER BY created_at DESC 
LIMIT 20;

Pra leituras típicas de apps web, MySQL costuma ser 10-20% mais rápido que PostgreSQL.

2. Replicação Simples

Configurar réplicas de leitura no MySQL é direto:

-- No primário
SHOW MASTER STATUS;

-- Na réplica
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST='primary.example.com',
    SOURCE_USER='replication_user',
    SOURCE_PASSWORD='password';
    
START REPLICA;

3. Ferramentas e Hosting

Todo provedor de hosting suporta MySQL. Toda ferramenta de backup suporta MySQL. Isso importa mais do que a gente gostaria de admitir.

4. Features Modernas do MySQL 8.x

-- Window functions (finalmente!)
SELECT 
    name,
    department,
    salary,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) as dept_rank
FROM employees;

-- CTEs
WITH regional_sales AS (
    SELECT region, SUM(amount) as total
    FROM orders
    GROUP BY region
)
SELECT * FROM regional_sales WHERE total > 1000000;

Onde MySQL deixa a desejar

• Queries complexas: Query planner toma decisões sub-ótimas mais frequentemente
• Tipos avançados: Sem tipo array nativo, JSON limitado
• Extensões: Nada comparável a PostGIS ou pgvector

MongoDB: O Banco de Documentos

MongoDB ocupa um nicho completamente diferente. Não é um substituto de bancos SQL—é uma alternativa quando modelos relacionais viram um peso.

O que MongoDB faz bem

1. Flexibilidade de Schema

Quando sua estrutura de dados é genuinamente imprevisível:

// Catálogo de produtos com atributos variados
db.products.insertMany([
  {
    name: "Camiseta",
    price: 29.99,
    sizes: ["P", "M", "G", "GG"],
    colors: ["vermelho", "azul", "preto"]
  },
  {
    name: "Notebook",
    price: 999.99,
    specs: {
      cpu: "M3 Pro",
      ram: "18GB",
      storage: "512GB SSD"
    }
  }
]);

2. Documentos Embarcados

Quando você lê grafos de objetos inteiros juntos:

// Post de blog com comentários - sem joins
db.posts.insertOne({
  title: "MongoDB em 2026",
  author: { name: "João", avatar: "/avatars/joao.jpg" },
  comments: [
    { user: "alice", text: "Ótimo post!", likes: 42 }
  ]
});

// Uma query retorna tudo
db.posts.findOne({ _id: postId });

3. Escalabilidade Horizontal

O sharding do MongoDB é built-in:

// Shardear uma collection
sh.shardCollection("mydb.orders", { customer_id: "hashed" });

// MongoDB distribui dados automaticamente

Pra datasets massivos (bilhões de documentos), o escalado horizontal do MongoDB é mais simples que PostgreSQL com Citus ou MySQL com Vitess.

4. Experiência do Desenvolvedor

O driver do MongoDB se sente nativo pra desenvolvedores JavaScript/TypeScript:

// Integração natural com JavaScript/TypeScript
const orders = await db.collection('orders')
  .find({
    status: 'pending',
    createdAt: { $gte: yesterday }
  })
  .sort({ createdAt: -1 })
  .limit(50)
  .toArray();

// Pipelines de agregação são poderosos
const salesByRegion = await db.collection('orders')
  .aggregate([
    { $match: { status: 'completed' } },
    { $group: { _id: '$region', total: { $sum: '$amount' } } },
    { $sort: { total: -1 } }
  ])
  .toArray();

Onde MongoDB deixa a desejar

• Transações: Multi-documento funciona mas é mais lento
• Joins: $lookup existe mas é menos eficiente
• Integridade de dados: Sem foreign keys significa checks de consistência na app
• Eficiência de storage: Documentos duplicam dados que seriam normalizados em SQL
• Queries complexas: Pipelines podem ficar complicados

Benchmarks de verdade

Bora ver dados reais de benchmarks 2024-2025:

Performance de Leitura Simples (ops/segundo, maior é melhor)

Performance de Escrita (ops/segundo, maior é melhor)

Performance de Queries Complexas (ms, menor é melhor)

*MongoDB precisa de desnormalização ou múltiplas queries
**Via pipeline de agregação

Conclusões principais:

• MySQL ganha em leituras simples de alto volume
• PostgreSQL ganha em queries complexas
• MongoDB ganha em operações de documentos e escritas
• Sua carga específica importa mais que benchmarks gerais

Como decidir

Escolha PostgreSQL se:

1. Tá construindo uma app nova do zero
2. Seus dados são relacionais
3. Precisa de queries complexas, reporting ou analytics
4. Quer um banco que faz tudo razoavelmente bem
5. Pode precisar de geoespacial, full-text ou vector search depois

Escolha MySQL se:

1. Usa WordPress, Drupal ou outro CMS PHP
2. Seu hosting é limitado a MySQL
3. Tem expertise e infra MySQL existente
4. Sua carga é principalmente leituras simples
5. Precisa de replicação testada com config mínima

Escolha MongoDB se:

1. Seus dados são genuinamente orientados a documentos
2. O schema evolui rápido e imprevisivelmente
3. Precisa de escalabilidade horizontal entre regiões
4. Seu time é heavy em JavaScript e prefere JSON
5. Tá construindo apps real-time (IoT, games, chat)
6. Tá prototipando e não sabe o schema final

Quando usar múltiplos bancos

Muitos sistemas em produção usam persistência poliglota:

┌─────────────────────────────────────────────────────────┐
│                     Aplicação                            │
├─────────────────────────────────────────────────────────┤
│  PostgreSQL          │  MongoDB         │  Redis        │
│  ─────────────       │  ────────        │  ─────        │
│  Usuários            │  Catálogo        │  Sessões      │
│  Pedidos             │  Event Logs      │  Cache        │
│  Transações          │  Conteúdo CMS    │  Rate Limits  │
└─────────────────────────────────────────────────────────┘

Isso tá de boa! Usa a ferramenta certa pra cada trabalho. Só não complica demais pra uma app pequena.

A controvérsia do MongoDB

Bora falar do elefante na sala: MongoDB foi super hypado no início dos anos 2010. Muitos times usaram pra cargas que PostgreSQL teria resolvido melhor, o que levou a dor e ao infame meme "MongoDB is web scale".

MongoDB NÃO é boa escolha pra:

• Transações financeiras que precisam de consistência forte
• Dados relacionais com joins complexos
• Apps que precisam de validação estrita de dados
• Times sem experiência com NoSQL

MongoDB SIM é boa escolha pra:

• Sistemas de gestão de conteúdo
• Logging de eventos e analytics
• Catálogos com atributos variados
• Dados em tempo real (IoT, games)
• Prototipagem rápida quando não sabe o schema

Considerações de migração

PostgreSQL ↔ MySQL

Os dois são SQL, então a migração é relativamente tranquila:

# MySQL pra PostgreSQL
pgloader mysql://user:pass@host/db postgresql://user:pass@host/db

# PostgreSQL pra MySQL (precisa de mais trabalho manual)
pg_dump --no-owner --no-privileges db | mysql db

Diferenças principais:

• AUTO_INCREMENT (MySQL) vs SERIAL (PostgreSQL)
• Backticks (MySQL) vs aspas duplas (PostgreSQL) pra identificadores
• LIMIT offset, count (MySQL) vs LIMIT count OFFSET offset (PostgreSQL)

SQL pra MongoDB

Migração de SQL pra MongoDB precisa de redesign do schema:

-- SQL: Estrutura normalizada
SELECT orders.*, customers.name, items.product_name
FROM orders
JOIN customers ON orders.customer_id = customers.id
JOIN order_items items ON items.order_id = orders.id
WHERE orders.id = 123;

// MongoDB: Documento desnormalizado
{
  _id: 123,
  customer: { id: 1, name: "João Silva" },
  items: [
    { product_name: "Widget", quantity: 2, price: 10.00 }
  ],
  total: 20.00,
  status: "enviado"
}

Não é só uma migração técnica—é uma mudança fundamental na filosofia de modelagem de dados.

Comparação de custos (2026)

Serviços gerenciados (mensal, specs comparáveis)

*DocumentDB é compatível com MongoDB, não é MongoDB em si

Self-Hosted (grátis, mas considera o custo de ops)

Os três são open source (MongoDB tem preocupações com a licença SSPL). Mas "grátis" não conta:

• O tempo dos seus engenheiros gerenciando o banco
• Infra de backup e recuperação
• Setup de alta disponibilidade
• Patches de segurança

Regra geral: Usa serviços gerenciados a menos que tenha um DBA dedicado ou restrições significativas de custo.

Conclusão: A recomendação honesta

Se chegou até aqui e ainda não consegue decidir:

Começa com PostgreSQL.

Não é porque PostgreSQL é objetivamente "o melhor"—é porque tem a melhor relação risco/recompensa pra maioria das apps:

1. Lida com 90% dos casos de uso bem
2. Não vai te limitar quando escalar
3. Tem o melhor ecossistema de extensões
4. É o padrão da indústria por boas razões
5. Sempre pode adicionar MongoDB ou Redis depois

MySQL continua excelente pra apps PHP e cargas de leitura onde você já tem expertise.

MongoDB é valioso quando você tem dados genuinamente orientados a documentos—só entra sabendo dos trade-offs.

As guerras de bancos de dados são majoritariamente tribais nesse ponto. Os três são tecnologias production-ready que alimentam as maiores apps do mundo.

Agora vai construir algo. O banco vai ficar bem.