MongoDB 9.0 usa menos CPU que 8.0 e 8.3 em benchmark independente da Percona

A Percona rodou o próprio benchmark do MongoDB↳MongoDB19 conteúdosMongoDB e LGPD: Quais os recursos disponíveis?Data · jul 2019Laravel & MongoDB: saiba mais sobre embedded documentsData · abr 2021LEFT JOIN no MongoDB, não é magia… É Aggregation Framework!!!Data · set 2019Ver tudo em Data → 9.0 contra 8.0 e 8.3, depois de não encontrar detalhes publicados sobre a metodologia usada pela MongoDB Inc. para chegar aos números de performance divulgados. O ganho existe, mas é modesto e depende do gargalo do seu servidor.

O que está em disputa e pra quem

Quando a MongoDB Inc. lançou a versão 9.0, divulgou números de performance que impressionaram, mas sem detalhar a metodologia. Foi o gancho do post anterior de Ivan Groenewold, engenheiro da Percona, que terminou aquele texto com um conselho direto:

Sempre rode seus próprios benchmarks.

Ivan Groenewold, autor no blog da PerconaAlways run your own benchmarks.

Em 6 de novembro de 2026, Groenewold publicou o resultado de seguir o próprio conselho. Ele comparou MongoDB Community 9.0.4 contra Percona Server for MongoDB (PSMDB) 8.0.34-15 e 8.3.13-4, três réplicas idênticas rodando no Google Cloud↳Google Cloud13 conteúdosPrograma da Google Cloud no Brasil projeta formar de forma gratuita 30 mil universitáriosDev (Back & Front) · mar 2026Google Cloud OnBoard capacita estudantes e desenvolvedores de TIGestão Dev & TI · mai 2019Desenvolvedores poderão participar de treinamento gratuito do Google CloudGestão Dev & TI · mai 2019Ver tudo em DevSecOps →, com uma carga de trabalho controlada.

O recorte interessa a quem decide se vale migrar um cluster MongoDB em produção para a versão 9.0, ou se o upgrade pode esperar. O critério de escolha do leitor aqui não é "qual versão é mais nova", mas sim: o gargalo do seu servidor hoje é CPU, memória ou disco? A resposta muda o tamanho do ganho esperado.

Vale uma ressalva que o próprio autor faz questão de repetir: é um teste rápido, com uma carga de trabalho, uma configuração de hardware e três tamanhos de dado. Não é benchmark extensivo, e ele mesmo trata os números como indicação inicial, não veredito.

Critérios de comparação

Análise por critério

O ganho de CPU é o achado central do teste. Groenewold mediu que o MongoDB 9.0 consome menos ciclos de CPU por operação em todos os três volumes de dados (1 milhão, 4 milhões e 8 milhões de documentos na coleção airline.flights). Esse detalhe explica por que o tamanho do ganho muda conforme o gargalo do servidor: quando a CPU satura, a economia aparece como throughput maior; quando não satura, ela some.

Com 1 milhão de documentos, toda a carga cabe confortavelmente no cache de arquivos do sistema operacional, então a diferença entre versões apareceu principalmente nas escritas (updateOne, updateMany, deleteOne, deleteMany, inserções em lote de 10 documentos). Os finds, que dominam 60% da carga, praticamente empataram entre as três versões nesse volume.

Com 4 milhões de documentos, o quadro virou: os finds passaram a mostrar a maior diferença, com o MongoDB 9.0 até 12% mais rápido que o PSMDB 8.0. É o ponto em que o WiredTiger cache já não segura tudo confortavelmente, e cada leitura que precisa ir ao disco custa CPU para descomprimir e processar, o que favorece a versão que gasta menos ciclos por operação. Esse é o cenário que o próprio autor descreve como de CPU limitante.

Com 8 milhões de documentos, a coleção comprimida (razão de compressão de cerca de 2:1) ficou do tamanho da memória total do servidor, deixando só 25% dos documentos de fato no WTcache. Nesse cenário de disco como limitador, as atualizações e exclusões de um único documento por flight_id (que precisam buscar um documento provavelmente fora de memória) ficaram iguais entre as versões, ou até levemente mais rápidas no PSMDB 8.0. O MongoDB 9.0 manteve vantagem só em finds, inserções e operações baseadas em _id.

Em resumo: o ganho de 9.0 é cerca de 6% quando a CPU é o fator limitante (cenário dos 4M documentos) e cai para cerca de 2% quando o gargalo passa a ser memória ou disco (cenário dos 8M documentos). O PSMDB 8.3 foi consistentemente a versão mais lenta sempre que a CPU importou, um comportamento que o próprio autor ainda não explicou e promete investigar num post seguinte.

Um ponto que elimina uma hipótese óbvia: os planos de execução. Depois de cada rodada, a ferramenta de carga (PLGM, Percona Load Generation Machine) rodou explain() em amostras de cada tipo de consulta. As três versões escolheram exatamente os mesmos planos, em todos os tamanhos de dado: LIMIT → FETCH → IXSCAN no índice flight_id_1_equipment.plane_type_1 para os finds, o mesmo caminho para updates e deletes por flight_id, e EXPRESS_UPDATE/EXPRESS_DELETE no índice _id_ para as operações em massa por identificador. Ou seja, a diferença de performance não vem de o otimizador escolher um caminho melhor ou pior: vem de quanto trabalho de CPU cada versão gasta para executar o mesmo plano.

A metodologia merece registro porque é incomum ver tanto detalhe em um benchmark de banco de dados. Groenewold publicou a configuração completa do ambiente (réplicas de três nós em instâncias n2-standard-4 no Google Cloud, discos pd-ssd, plataforma Intel Ice Lake), os parâmetros do PLGM (16 workers sem tempo de espera entre comandos, PLGM_WORKLOAD_DETERMINISTIC=true, sementes fixas) e até o hash de fingerprint do tráfego gerado, para que qualquer pessoa reproduza o teste byte a byte. As escritas usaram o write concern padrão do servidor, então incluem replicação no tempo medido, o que aproxima o teste de uma produção real em réplica set.

Veredito por caso de uso

Para quem administra um cluster onde a CPU já está no limite (relatórios pesados, muitas conexões concorrentes, carga de leitura intensa competindo com escrita), o MongoDB 9.0 oferece um ganho real e mensurável de cerca de 6%. Vale reservar um ambiente de homologação e repetir um teste parecido com a carga típica da aplicação antes de decidir.

Para quem roda um banco pequeno ou médio onde os dados cabem confortavelmente no cache de memória, o ganho cai para cerca de 2%, o que dificilmente justifica a janela de manutenção e o risco de um upgrade maior de versão em produção. Nesse caso, a migração pode esperar o próximo ciclo normal de atualização.

Para quem já usa PSMDB 8.3 especificamente por features exclusivas da Percona (o teste desabilitou todas elas para manter a comparação justa), o resultado pede cautela redobrada: 8.3 foi a versão mais lenta sempre que a CPU importou, e ainda não há explicação publicada para isso. Antes de migrar para 9.0 abandonando 8.3, vale rodar o mesmo teste com as features da Percona habilitadas, porque elas podem mudar o quadro.

Para equipes que já têm um motivo independente para migrar, como fim de suporte de uma versão antiga, o resultado é tranquilizador: não há sinal de regressão de latência ou de throughput entre 8.0, 8.3 e 9.0 no padrão de carga testado. A migração pode seguir pelo cronograma normal, com a expectativa de um ganho pequeno de brinde, não de uma razão para acelerar o plano.

O próprio autor resume o tom que deve orientar qualquer decisão:

Trate o 9.0 como uma versão para testar, não uma que você precisa implantar às pressas.

Ivan Groenewold, autor no blog da PerconaTreat 9.0 as a release to test, not one you have to deploy urgently.

O que ainda não dá pra afirmar

O teste cobriu uma única carga de trabalho, a "flights" embutida no PLGM (coleção airline.flights com 7 índices secundários, mistura de 60% finds, 20% updates, 10% deletes e 10% inserções). Workloads com agregações pesadas, transações multi-documento ou padrões de acesso muito diferentes (o teste rodou com PLGM_AGGREGATE_PERCENT=0 e PLGM_TRANSACTION_PERCENT=0) não foram medidos e podem reagir de outra forma.

Também falta variar a concorrência e o tipo de disco. O autor usou 16 workers fixos e SSD padrão do Google Cloud, e já anuncia que o próximo passo é testar outros níveis de concorrência e discos mais rápidos, além de investigar por que o PSMDB 8.3 consome mais CPU que as outras duas versões.

Não há, até o momento desta publicação, uma réplica desse teste rodada por terceiros, nem uma comparação direta com os números originais divulgados pela MongoDB Inc. (que motivaram o post anterior de Groenewold, justamente por falta de detalhes de metodologia publicados). Enquanto isso não acontece, o resultado da Percona é a referência mais transparente disponível, mas continua sendo, nas palavras do próprio autor, "um primeiro teste rápido, não um benchmark extensivo por qualquer medida".

O material fornecido pela fonte não trouxe nenhuma URL de imagem ou vídeo compatível com os critérios de mídia deste veículo, por isso o texto segue sem elemento visual embutido.

Fonte

1. Percona Database Blog: "MongoDB 9.0 vs. 8.0 vs. 8.3: A Quick First Look at Performance", de Ivan Groenewold, publicado em 6 de novembro de 2026 (https://www.percona.com/blog/mongodb-9-0-vs-8-0-vs-8-3-a-quick-first-look-at-performance/).

Fonte: Percona Database Blog