PostgreSQL ou MongoDB: a carga muda o vencedor

Na avaliação de 80 cenários por sistema, o PostgreSQL com JSONB teve maior vazão na maioria das cargas de documentos, mas o MongoDB levou vantagem em condições específicas de leitura com pouca concorrência e de escrita sob carga máxima. O resultado para uma aplicação depende da mistura de operações, do volume de dados e de quantos acessos ocorrem ao mesmo tempo.

Para escolher entre eles, importa também definir o que constitui um registro. Dados normalmente lidos juntos podem favorecer um documento; entidades consultadas por relações variadas podem favorecer tabelas. Se muitas transações alteram o mesmo registro, a unidade que cada banco bloqueia ou atualiza passa a influenciar a decisão tanto quanto a velocidade de leitura.

O que entrou na matriz de comparação

O experimento cruzou quatro misturas de leitura e escrita — 100/0, 95/5, 80/20 e 70/30 — com bases de 10 mil, 100 mil, 500 mil e 1 milhão de registros. Para cada combinação, foram usados cinco níveis de concorrência, de 60 a 960 usuários virtuais, com três execuções por cenário. A carga sintética empregou documentos JSON e uma distribuição de acessos em que algumas chaves são procuradas mais que outras.

O PostgreSQL armazenou os documentos em JSONB no serviço da Aiven; o MongoDB foi executado no Atlas. Os ambientes tinham planos e configurações próprios, e os pesquisadores ajustaram a configuração de escrita do MongoDB para aproximar as garantias de durabilidade. Portanto, a diferença medida pertence a essas combinações de banco, serviço e carga. O teste não comparou um esquema relacional normalizado com um esquema de documentos, nem incluiu as consultas entre várias entidades que podem dominar outra aplicação.

Leitura: a consulta rápida nem sempre entrega mais vazão

Nas medições, o MongoDB apresentou menor latência média por operação de leitura, enquanto o PostgreSQL concluiu mais operações por segundo em boa parte dos cenários com concorrência maior. Nas cargas só de leitura e com poucos usuários virtuais, a vazão do MongoDB foi superior; essa vantagem diminuiu quando aumentou o número de acessos simultâneos. Latência descreve a espera por uma operação, e vazão descreve o volume total concluído no mesmo intervalo: são respostas a perguntas diferentes.

Isso interessa especialmente quando a leitura principal recupera uma unidade de dados bem delimitada, como um documento por identificador. Se a tela ou a API também precisa filtrar atributos de entidades relacionadas, montar agregações e oferecer caminhos diferentes de consulta, o trabalho já não se parece com aquela busca simples. A estrutura dos dados e os índices necessários podem mudar o custo da operação antes mesmo de a concorrência aumentar.

Escrita: o registro disputado define a contenção

Atualizações de partes diferentes de um documento JSONB disputam a mesma linha no PostgreSQL.

Nas misturas de leitura e escrita, o PostgreSQL liderou a vazão na maior parte das condições avaliadas. A exceção mais clara apareceu na mistura com maior participação de escritas sob o nível máximo de usuários virtuais, quando o MongoDB entregou mais operações por segundo. Mesmo nessa condição, a análise de latência de escrita favoreceu o PostgreSQL. Para uma aplicação sensível ao tempo de cada atualização, a vazão total, sozinha, não resolve a escolha.

A documentação do PostgreSQL sobre JSON explica que atualizar um valor armazenado na tabela adquire bloqueio sobre a linha inteira. Assim, transações que alteram campos diferentes de um mesmo documento JSONB ainda disputam a mesma linha. Um documento grande, com partes que mudam independentemente, pode concentrar esperas que uma divisão em linhas próprias reduziria.

Esse limite não torna JSONB inadequado para dados flexíveis: o PostgreSQL permite combinar documentos e colunas relacionais. A pergunta é se os campos pertencem à mesma unidade de atualização. Se endereço, preferências e histórico de uma entidade são modificados por fluxos distintos, reuni-los em uma única linha amplia a área de disputa; separá-los exige considerar as consultas que depois precisarão recompor esses dados.

Incorporação ou referência muda o trabalho do MongoDB

Documentos do MongoDB mostram avaliações incorporadas ao produto e avaliações mantidas por referência.

O guia de modelagem do MongoDB recomenda escolher entre incorporar e referenciar dados relacionados conforme o padrão de acesso da aplicação. Seu exemplo de catálogo mantém avaliações recentes junto ao produto e pode deixar as antigas em outra coleção. A flexibilidade dos campos permite adaptar a estrutura dos documentos, mas a decisão sobre quais dados ficam juntos continua determinando quantas operações uma consulta exige.

A orientação sobre incorporação descreve a vantagem de recuperar dados relacionados em uma única operação e atualizá-los atomicamente dentro do documento. Isso combina com informações que costumam ser lidas no contexto da entidade principal. O crescimento, porém, precisa ter um limite: o MongoDB impõe tamanho máximo ao documento, e incluir cada novo elemento em uma lista que cresce continuamente altera o custo de manter essa unidade.

A orientação sobre referências aponta outra saída quando a entidade relacionada é consultada por conta própria, muda com frequência ou participa de relações complexas. Manter documentos separados evita certas duplicações e permite ciclos de atualização independentes, mas pode exigir buscas adicionais para reunir os dados. O ganho de uma leitura em documento único deixa de existir se a aplicação precisa reconstruir repetidamente relações espalhadas.

Qual modelo combina com a carga real

Se as consultas principais cruzam entidades por relações e filtros variados, o PostgreSQL relacional é um ponto de partida consistente. JSONB pode abrigar atributos flexíveis sem obrigar que relações centrais fiquem escondidas dentro de um documento.
Se a operação dominante recupera um conjunto estável de dados de uma vez, vale avaliar documentos MongoDB com dados relacionados incorporados. A escolha fica mais forte quando esses dados também têm crescimento limitado e costumam ser atualizados juntos.
Se as entidades relacionadas são consultadas ou modificadas separadamente, compare tabelas com documentos referenciados. Nesse caso, conte as leituras necessárias para reuni-las e o custo de manter cópias, em vez de tratar a ausência de uma junção como vantagem automática.
Se há muitas atualizações concorrentes, identifique quais registros recebem essas escritas. No PostgreSQL, campos independentes na mesma linha JSONB disputam seu bloqueio; no MongoDB, incorporar componentes com ciclos de mudança distintos também concentra trabalho no mesmo documento.

A medição mais útil reproduz as consultas, atualizações, índices e garantias de durabilidade exigidos pela aplicação. A matriz publicada delimita situações em que a liderança de vazão mudou; o desenho das relações e a concentração das escritas determinam se uma dessas situações corresponde à carga que será atendida.