Quando usar MongoDB: o modelo de documentos faz sentido?

Você abriu o MongoDB porque alguém no time disse que "schema rígido atrasa o produto", modelou tudo como documento aninhado e, três meses depois, está escrevendo $lookup em cima de $lookup para juntar pedidos, clientes e pagamentos. A sensação é familiar: você reinventou o JOIN, só que mais lento e sem garantias transacionais. O problema raramente é o MongoDB. É ter escolhido o modelo de documentos para um dado que, no fundo, é relacional.

A pergunta certa não é "MongoDB é melhor que Postgres?". É "o meu dado é naturalmente um documento ou uma rede de relações?". Este guia responde isso com critérios concretos, não com slogans.

O que é, de fato, um documento

No modelo relacional você quebra uma entidade em várias tabelas normalizadas e remonta com JOINs na hora da leitura. No MongoDB você guarda a entidade inteira como ela é consumida: um pedido com seus itens, endereço de entrega e snapshot do cliente, tudo num único documento JSON-like (BSON).

{
  "_id": "ord_8821",
  "cliente": { "nome": "Ana Lima", "email": "ana@ex.com" },
  "itens": [
    { "sku": "TEC-01", "qtd": 2, "preco": 149.9 },
    { "sku": "MOU-03", "qtd": 1, "preco": 89.0 }
  ],
  "total": 388.8,
  "status": "pago"
}

A regra de ouro do MongoDB é: dados acessados juntos ficam guardados juntos. Se a sua tela mostra o pedido inteiro de uma vez, ler esse documento é uma única ida ao disco, sem JOIN. É aí que o modelo de documentos brilha — e é exatamente aí que a maioria das pessoas erra ao avaliar a tecnologia.

Quando documentos fazem mais sentido

Documentos vencem quando o formato do dado e o padrão de acesso conspiram a favor:

• A entidade é lida e escrita como um bloco. Carrinho, perfil de usuário, configuração de conta, post com comentários embutidos. Você quase nunca quer "só os itens" sem o pedido.
• O schema varia entre registros. Catálogo de produtos onde uma TV tem polegadas e uma camiseta tem tamanho. No relacional isso vira coluna nula ou tabela de atributos genérica (o famigerado EAV); no documento, cada produto carrega só os campos que tem.
• O dado evolui rápido. Em estágio inicial de produto, o schema muda toda semana. Adicionar um campo a alguns documentos não exige ALTER TABLE em milhões de linhas.
• Você precisa escalar horizontalmente. O sharding nativo do MongoDB distribui documentos por chave entre nós. É um caminho mais direto que o sharding manual de um relacional.
• O dado já chega semiestruturado. Eventos, logs, payloads de webhook, telemetria — coisas que entram em formatos irregulares e de alto volume.

Repare no padrão: todos esses casos têm uma fronteira de agregação clara. O documento é a unidade natural de leitura e de escrita.

Quando documentos atrapalham (e tabelas ganham)

Aqui mora o erro de origem. O modelo de documentos cobra caro quando o dado é, na essência, uma rede de relações muitos-para-muitos consultada de ângulos diferentes:

• Você precisa de muitos JOINs entre entidades independentes. Se cada query exige $lookup ligando coleções distintas, isso é um sinal forte de que o dado é relacional. JOIN no MongoDB existe, mas não é o terreno onde ele corre melhor.
• Transações precisam ser ACID em várias entidades. O MongoDB suporta transações multi-documento desde a 4.0, mas elas têm custo e limites — não é o desenho para o qual o banco foi otimizado. Movimentação financeira entre contas é o exemplo clássico que pede relacional.
• A mesma informação é consultada por vários eixos. Um relatório que cruza vendas por região, por vendedor e por produto se beneficia de tabelas normalizadas e SQL maduro. Duplicar isso em documentos vira pesadelo de consistência.
• Compliance exige relacional. Adquirentes e órgãos de pagamento frequentemente só homologam dados financeiros em RDBMS tradicionais. É menos engenharia e mais regulação.

Existe ainda o custo silencioso: para evitar JOINs você duplica dados (o snapshot do cliente em cada pedido, por exemplo). Isso consome mais disco e cria o problema de manter cópias sincronizadas quando o original muda. Se você se pegou escrevendo rotinas para propagar uma atualização de nome de cliente por 40 mil documentos, o modelo está errado para esse dado.

Embutir ou referenciar: a decisão que define tudo

Dentro do próprio MongoDB existe a escolha que mais separa projetos saudáveis de projetos sofridos: embedding (aninhar) versus referencing (referenciar por id, estilo chave estrangeira).

Embuta quando a relação é de contenção e o filho não vive sozinho: itens de um pedido, comentários de um post com baixo volume. Referencie quando o sub-objeto é grande, cresce sem limite, ou é compartilhado por vários pais.

// Embedding — itens vivem dentro do pedido
db.pedidos.findOne({ _id: "ord_8821" })  // tudo em 1 leitura

// Referencing — comentários numa coleção própria
db.comentarios.find({ post_id: "post_42" }).limit(20)

Documentos no MongoDB têm limite de 16 MB. Uma lista que cresce para sempre — como o feed de atividades de um usuário ativo há anos — não pode ser embutida; ela vai estourar o documento. Esse limite é, na prática, o seu detector de modelagem errada.

A escolha não é binária

Times maduros não escolhem "MongoDB ou Postgres" para o sistema inteiro. Eles escolhem por contexto: catálogo de produtos e sessões no documento, livro-razão financeiro no relacional. Se você quer entender a diferença mais ampla entre as duas famílias de banco — incluindo consistência, escalabilidade e modelos de transação — vale ler o nosso comparativo sobre banco relacional vs NoSQL, que trata da decisão num nível mais arquitetural. Este guia aqui é o zoom no caso específico do documento.

Postgres, aliás, tem o tipo JSONB, que guarda documentos com índices. Para uma fatia pequena de dado flexível dentro de um sistema majoritariamente relacional, isso muitas vezes resolve sem trazer um segundo banco para operar.

Perguntas frequentes

Quando usar MongoDB ao invés de um banco relacional?

Quando a entidade é lida e escrita como um bloco coeso, o schema varia entre registros, o dado evolui rápido ou você precisa de escala horizontal simples. Se o seu padrão de acesso é "pega o documento inteiro por uma chave", o modelo de documentos é direto e rápido.

Quando NÃO usar MongoDB?

Quando o dado é uma rede de relações muitos-para-muitos consultada por vários ângulos, quando você precisa de transações ACID firmes entre entidades distintas, ou quando o domínio (tipicamente financeiro) exige RDBMS por compliance. Se você está escrevendo $lookup em quase toda query, o dado é relacional.

MongoDB consome mais espaço em disco que um relacional?

Em geral sim, porque o modelo de documentos costuma duplicar dados para evitar JOINs — o snapshot do cliente em cada pedido, por exemplo. Você troca espaço em disco por velocidade de leitura e por evitar JOINs. O cuidado real não é o disco em si, e sim manter as cópias consistentes quando o original muda.

Dá para usar MongoDB e um banco relacional no mesmo projeto?

Sim, e é comum. Use cada banco onde ele é forte: documentos para entidades autocontidas e de schema variável, relacional para o núcleo transacional e relatórios cruzados. Postgres com JSONB também é um meio-termo válido quando a parcela flexível é pequena.

O que levar deste guia

O modelo de documentos não é "o futuro" nem "moda passageira" — é uma escolha de forma de dado. Pergunte-se: a minha entidade tem uma fronteira de agregação clara, é lida como um bloco, e o limite de 16 MB me dá folga? Se sim, o documento vai te servir bem e te poupar de JOINs. Se você se vê reconstruindo JOINs com $lookup, sincronizando cópias na mão ou brigando com transações entre coleções, o sinal é claro: aquele dado queria ser uma tabela desde o começo.