PostgreSQL vs MongoDB: como escolher
Rede de relações ou agregados autocontidos? Os critérios reais de escolha, o segredo do jsonb que desmonta o debate antigo e o erro clássico de cada lado.
Essa escolha já foi tribal: SQL contra NoSQL, tradição contra modernidade. A poeira baixou, e a fotografia atual é mais interessante: PostgreSQL virou o canivete suíço padrão do mercado, e o MongoDB amadureceu em nichos onde o modelo de documentos brilha de verdade. A escolha certa depende de reconhecer qual história é a sua.
A diferença que realmente importa: o formato dos dados
PostgreSQL é relacional: dados em tabelas normalizadas, relações explícitas, integridade garantida pelo banco (chaves estrangeiras, constraints, transações ACID completas). O esquema é um contrato: ninguém grava um pedido sem cliente válido (postgresql.org).
MongoDB é orientado a documentos: cada registro é um JSON (BSON) autocontido, com estrutura flexível. O pedido carrega dentro de si os itens, o endereço, o snapshot do cliente. Leitura de um agregado inteiro = uma consulta, sem joins (mongodb.com).
A pergunta de decisão nasce daí: seus dados são uma rede de relações consultada de vários ângulos, ou agregados autocontidos consultados quase sempre inteiros?
- Financeiro, estoque, pedidos, qualquer coisa com consistência crítica e relatórios cruzados: a rede relacional cobra menos caro a longo prazo.
- Catálogos com atributos variáveis por tipo de produto, perfis/preferências, conteúdo de CMS, telemetria de dispositivos heterogêneos: o documento evita um esquema-espaguete de tabelas de atributos.
Os dois segredos que desmontam o debate antigo
1. O Postgres também fala JSON. O tipo jsonb (com índices GIN) guarda documentos flexíveis dentro de colunas relacionais. O padrão híbrido resolve a maioria dos casos "preciso de flexibilidade": o pedido é relacional; o campo atributos do produto é um documento indexável.
SELECT * FROM produtos
WHERE atributos @> '{"cor": "azul", "voltagem": "220v"}';
-- consulta por dentro do JSON, com índice
Na prática de consultoria, essa é a resposta mais frequente: Postgres como base, jsonb onde a flexibilidade é real. Um sistema, dois modelos.
2. "Mongo é mais rápido" depende de onde você mede. Ler um agregado inteiro? O documento vence, é uma busca só. Cruzar dados por ângulos que o documento não previu ("todos os pedidos com o produto X em dezembro, por região")? O relacional vence com folga, e o documento paga em $lookup caros ou em duplicação de dados. Performance não é do banco; é do alinhamento entre modelo e padrão de acesso, tema do quarto artigo desta série.
Os critérios de desempate
- Transações multi-registro são rotina? Débito aqui + crédito ali + baixa de estoque, tudo ou nada: o ACID do Postgres é o caminho natural. (MongoDB tem transações multi-documento desde a 4.0, mas se você as usa o tempo todo, está lutando contra o modelo.)
- Relatórios e BI em cima da base? O ecossistema SQL (ferramentas, gente, integrações) é imbatível. Todo analista fala SQL; seu dashboard agradece.
- Escala horizontal nativa como requisito real? O sharding do MongoDB é maduro e operacionalmente mais simples que particionar Postgres na mão. Mas seja honesto sobre o "requisito": a maioria dos sistemas nunca chega lá, e Postgres bem indexado numa máquina parruda atende bilhões de linhas.
- Time e operação: quem cuida do banco às 3h? Postgres gerenciado existe em todas as nuvens; MongoDB Atlas é excelente e cobra por isso.
O erro clássico de cada lado
Com MongoDB: modelar como se fosse relacional: documentos magros cheios de referências, "joins" em aplicação, e o pior dos dois mundos. Documento pede desenho por agregado, com duplicação deliberada.
Com PostgreSQL: o oposto: EAV (tabelas entidade-atributo-valor) para simular flexibilidade, quando um jsonb resolveria com índice e sanidade.
Nos dois casos, a raiz é a mesma: escolher o banco antes de entender como os dados serão consultados. O modelo segue o acesso, nunca o contrário.
A recomendação honesta
Na dúvida, comece com PostgreSQL: cobre o caso geral, flexibiliza com jsonb, tem o maior ecossistema e não te tranca em nada. Adote MongoDB quando o modelo de documentos casar com seus agregados e o time souber operá-lo, aí ele é excelente, não um vice.
Esse tipo de decisão de persistência (e a modelagem que vem junto) é parte do nosso serviço de Arquitetura de Software.
Descreva sua entidade mais complexa para a IA da Rabelo Digital, aqui no canto da tela (como ela é lida e escrita), e ela indica o modelo com melhor encaixe. Sem formulário, sem espera.
Deixe um Comentário