Por dentro do MongoDB 9.0: o que muda no core do banco

O MongoDB 9.0 está disponível desde 28 de Setembro e foi apresentada oficialmente durante o MongoDB.local NYC em 30/09. Na minha opinião não é a versão de uma feature só: é a versão de um banco mais rápido com upgrade e, principalmente, mais previsível quando a carga foge do controle. Eu acompanhei a sessão de roadmap do core no MongoDB Champions Summit, dois dias antes do evento, e aqui mostro um o que muda de verdade, o que dá para usar hoje e o que eu vou testar antes de subir.

Performance: mais banco pelo mesmo hardware

Comparada com a 8.0, a MongoDB divulga para a 9.0 até 35% mais velocidade em findOne, até 30% em updateOne, até 2x de throughput em instâncias grandes e cerca de 20% a mais de throughput em cargas "transacionais". Na sessão, o time explicou que os dois primeiros números vêm de benchmarks de operações pontuais e o último de cargas com transações multi-documento, no estilo TPC-C e TPC-E. Parece ser só uma ou outra operação, mas as operações com "one" devem ser exploradas mais em nossas aplicações, na prática e volume do dia-a-dia isso faz bastante diferença.

O ganho não veio de uma feature nova. Veio de três frentes:

• Limpeza do motor de execução. Desde o ciclo da 8.0, performance virou meta da MongoDB como empresa. Times dedicados passaram meses revisando o caminho de execução de queries, até o nível de tickets de execução e implementações de mutex.
• Otimização de compilação. Link-time optimization, profile-guided optimization (PGO) e reordenação de símbolos no build, para manter o código mais usado junto e quente no cache da CPU.
• Escala vertical. Melhorias no software para aproveitar máquinas maiores. No Atlas, isso se soma ao hardware Gen2, esse ponto entra num próximo artigo especificamente sobre Atlas.

Na prática, é ganho que chega com o upgrade, sem mudar uma linha da aplicação. Mas quero deixar claro que são números de laboratório, e a metodologia completa não foi publicada. Como sempre diz meu amigo Otávio Santana: o melhor benchmark é o seu! Antes de "cravar" qualquer porcentagem para o seu time, rode um com a sua carga.

Segurança: busca por pedaço de texto em dados criptografados

A novidade mais concreta de segurança é que o Queryable Encryption agora aceita consultas de prefixo, sufixo e substring, em GA. Até aqui, ele só fazia igualdade e range. Vale relembrar o conceito: o dado é criptografado no cliente, fica criptografado no banco e continua criptografado em memória durante a consulta. O servidor nunca vê o valor em claro.

Isso destrava casos que antes forçavam a decriptar no app casos que fazem diferença não só na segurança mas também na experiência do usuário: autocomplete do nome de cliente, busca pelos primeiros ou últimos dígitos de um CPF, filtro por domínio de e-mail. Para quem lida com LGPD em fintech, saúde ou seguros, ou em qualquer outro segmento é a diferença entre criptografar o campo sensível ou deixá-lo de fora porque a tela de busca precisava dele.

O que precisa ser decidido na criação da coleção, para cada campo:

Parâmetro	Para que serve
queryType	prefix, suffix ou substring (podem coexistir no mesmo campo)
strMinQueryLength / strMaxQueryLength	Tamanho mínimo e máximo do trecho buscado. Em substring, o máximo vai de 2 a 6 e pesa muito na performance
strMaxLength	Obrigatório em substring: tamanho máximo do valor armazenado, de 2 a 50
caseSensitive / diacriticSensitive	Se a busca diferencia maiúsculas e acentos. Precisa ser igual em todos os tipos de busca do campo

Os cuidados: cada campo consultável ganha um índice e aumenta o custo de escrita e de storage, regex continua sem suporte, e mudar o esquema de criptografia significa recriar a coleção. Quem testou o preview na 8.2 ou 8.3 deve contar com isso, porque a implementação GA não é compatível com a do preview. O mongocryptd foi depreciado: o caminho agora é a Automatic Encryption Shared Library (crypt_shared), sem processo separado.

A outra frente é o "hardening" do próprio produto. Segundo o time de produto, a MongoDB participa em parceria de alguns projetos, usando modelos avançados para achar e corrigir vulnerabilidades antes que sejam exploradas. Para tornar a entrega previsível, as correções de segurança passam a sair no estilo Patch Tuesday, na segunda terça-feira do mês. A 9.0.2, publicada no mesmo dia do GA (28/09/2026), já corrige a CVE-2026-89099. Dica importante: não suba para 9.0.0, vá direto para o último patch.

Pequenos ajustes que DBAs vão gostar: o log de auditoria ganhou o campo directRemote (direct_endpoint no schema OCSF), que registra o IP TCP real de quem abriu a conexão, separado do endereço informado via PROXY protocol por um load balancer. O campo também chegou às versões 8.0.33 e 8.3.9. Além disso, o novo parâmetro useInternalAuthzForX509 permite que clientes X.509 usem a autorização interna do MongoDB mesmo com autorização LDAP configurada.

Resiliência: o cluster que não cai, se adapta

Para mim, o Intelligent Workload Management (IWM) é a mudança mais importante da 9.0 para quem opera. A pergunta que o time fez na sessão resume o problema: quantos nós já foram acionados porque o banco estava lento, e não fora do ar? Num pico de Black Friday ou de ações, campanhas, chegam juntos o tráfego, os retries de conexão e aquela query sem índice. A pressão vai se acumulando, a latência dispara e alguém acaba resgatando o cluster na mão. Que como sabemos essa ação vem sempre acompanhada de alguns efeitos colaterais indesejáveis.

O IWM transforma esse cenário num evento controlado. Ele não adiciona capacidade nem substitui o auto-scaling: ele ganha tempo até o auto-scaling ou um operador agir. Isso funciona em camadas, veja:

1. Fila na entrada. Um rate limiter por mongod admite operações num ritmo seguro e enfileira o excesso, em vez de deixar tudo competir por CPU. A fila é de controle de admissão: nada que está nela foi aceito ainda, então não há o que persistir.
2. Prioridade para o que é curto. A gente concorad que toda operação nasce "curta". Se ela cede (yield) vezes demais, é reclassificada como longa e vai para uma fila de menor prioridade. Leituras e escritas pontuais seguem, enquanto relatórios pesados, scans sem índice e tarefas internas desaceleram, mas continuam progredindo.
3. Proteção de recursos. Ajuste de cache e memória sob pressão, limitação de novas conexões em enchurradas de reconexão e bloqueio de escrita quando o disco está criticamente cheio (leituras continuam).
4. Load shedding, opcional. Em um estado de sobrecarga sustentada, a fila passa a ter limite e o excesso é rejeitado com um erro (sinalizando essa sobrecarga) retentável. Numa linha parecida como o Retryable Writes, lembra dele?

As camadas 1 a 3 estão sempre ligadas em clusters dedicados do Atlas na 9.0, sem custo extra e sem mudar a aplicação. O load shedding é opt-in e exige ordem: primeiro atualize o driver, depois ligue o recurso. Os drivers compatíveis com backpressure entendem o erro de sobrecarga e fazem retry com backoff e jitter. Com um driver antigo, a aplicação recebe o erro sem saber tratá-lo. O Atlas disponibiliza um teste de load shedding que rejeita uma pequena porcentagem de operações de propósito, para validar o tratamento de erro. Utilize em dev ou staging para testar o comportamento das aplicações, mas nunca no cluster principal.

Proteção	M10/M20	M30+ replica set	M30+ sharded
Fila na entrada e priorização	Não	Sim	Não (por enquanto)
Cache/memória, conexões, bloqueio de escrita	Sim	Sim	Sim
Load shedding (opt-in)	Não (por enquanto)	Sim	Não (por enquanto)

Perguntas que fizemos durante a sessão deixaram alguns pontos mais claros:

• Não é configurável por requisição. Fila ou load shedding é uma escolha do cluster. Priorizar por workload ("esta operação assíncrona pode esperar, esta com cliente na tela não") está no backlog.
• A fila é FIFO, por enquanto. O tamanho é limitado pelo número de conexões do cluster. As políticas rodam num policy engine separado do servidor, que pode evoluir mais rápido que as versões do banco.
• Sobrecarga é medida por utilização de recursos, principalmente CPU, e pelo tempo de espera no controle de execução.
• O auto-scaler ficou menos conservador. Um caso em que um index build travou as transações e o próprio auto-scaling. A boa notícias é que o algoritmo mudou para casos assim.
• É só Atlas, por ora. Para Enterprise Advanced, a resposta foi "paridade eventual".

Para acompanhar, o Atlas expõe as métricas Operation Rate Limiting e Connection Rate Limiting, alertas específicos de IWM e eventos no Activity Feed.

Observabilidade e controle de queries

No core, o avanço é o $queryStats passar a enxergar escritas. Agora insert, update e delete também geram estatísticas por query shape, ligadas por padrão via amostragem de 1% (internalQueryStatsSampleRate para leituras e internalQueryStatsWriteCmdSampleRate para escritas). A saída ganhou os blocos metrics.cursor, metrics.queryExec, metrics.queryPlanner e metrics.writes. Se você tem tooling que lê essa saída, revise antes do upgrade.

O controle fino de queries também melhorou:

• querySettings direto no comando. Você passa as configurações no próprio find, distinct ou aggregate, valendo só para aquela execução. Se o shape tiver configuração salva com setQuerySettings, a salva vence no mesmo campo.
• maxTimeMS por query shape, definido com setQuerySettings. Útil para conter aquela query problemática sem deploy.
• queryKnobs, para sobrescrever parâmetros internos do servidor em um único shape. Os dois últimos exigem FCV 9.0.

Do lado do Atlas, o pilar de observabilidade da 9.0 inclui exportação nativa via OpenTelemetry (Prometheus, Grafana, Datadog, New Relic, sem camada de tradução), a nova Metrics UI e o Query Shape Insights cobrindo escritas.

Produtividade: MongoDB agora fala Hibernate

A MongoDB Extension for Hibernate ORM está em GA. É a mesma API de Session, as mesmas anotações @Entity e o mesmo HQL que o time Java já conhece, com o MongoDB embaixo. A extensão traduz a árvore de SQL do Hibernate para MQL: um join em HQL vira $lookup, um order by vira $sort. A própria Hibernate tentou algo parecido com o Hibernate OGM e descontinuou, por ser genérico demais. Nesta nova abordagem o escopo é só MongoDB. Desenhado especificamente para Java, mas abre o caminho para o reaproveitamento em drivers de outras linguagens, além de reaproveitamento do conceito e código para ferramentas de de migração como o Relational Migrator

O que vem no GA:

• HQL com os operadores mais usados (group by, in, between, agregações, caminhos aninhados).
• Inner join e left outer join. Outros tipos de join estão no roadmap pós-GA.
• Subdocumentos e arrays como mapeamento de primeira classe, sem achatar o modelo em tabelas.
• Starter para Spring Boot, optimistic locking, índices, unique constraints e logging estruturado.
• Native queries para o que o HQL não cobre, incluindo $search e $vectorSearch.

Requisitos: Java 17+, Hibernate ORM 7.4, MongoDB 7.0 ou superior em replica set (o standalone não tem transações), licença Apache 2.0, artefato org.mongodb:mongodb-hibernate no Maven. Ainda sem cache de segundo nível, sem @DataJpaTest e sem validação em GraalVM native image. O próximo passo citado é expor Queryable Encryption e Vector Search pelo próprio Hibernate, além de uma extensão para Quarkus.

Para quem faz migração de relacional, isso muda a conversa. O time de modernization da MongoDB já usa a extensão como dependência. Mas modelar documento continua sendo trabalho: reaproveitar as entidades de um esquema relacional sem repensar o modelo só troca o banco de lugar.

Ciclo de vida: cinco anos para planejar

Parece apenas mais um detalhe, mas é o que mais pesa em empresa grande: cada major version tem ciclo de vida de cinco anos, no Atlas e em Enterprise Advanced. Majors saem a cada dois anos. Entre elas, minors trimestrais chegam pelo auto-upgrade do Atlas e, desde a 8.2, também on-premises para casos específicos. Correções de segurança seguem o ritmo mensal citado acima.

Na prática, quem fica na 9.0 tem uma janela real para planejar a próxima migração sem correr atrás de EOL todo ano. Quem quer as novidades primeiro usa o "Latest Version With Auto Upgrades" no Atlas, sabendo que, ao passar de major para minor, não dá para voltar para major até a próxima sair.

A 9.0 também é a primeira major a incluir Search e Vector Search self-managed em Enterprise Advanced e Community, para quem quer busca sem um sistema à parte e sem Atlas. Esse é um assunto bastante pedido e pede um artigo detalhado sobre como implementar!

Onde cada novidade está disponível

A 9.0 é o mesmo motor em Atlas, Enterprise Advanced e Community, mas nem tudo que foi anunciado como "9.0" (por enquanto) roda fora do Atlas.

Novidade	Status	Atlas	Enterprise Advanced	Community
Ganhos de performance do motor	GA	Sim	Sim	Sim
Queryable Encryption: prefixo, sufixo, substring	GA	Sim	Sim	Sim, só com criptografia explícita (a automática não é Community)
Intelligent Workload Management	GA	Sim, clusters dedicados	Paridade futura, sem data	Não
Load shedding	GA, opt-in	M30+ replica set	Não	Não
querySettings por comando, maxTimeMS por shape	GA	Sim	Sim	Sim
Validação constraint	GA	Sim	Sim	Sim
Extensão Hibernate ORM	GA	Sim	Sim	Sim (7.0+, replica set)
OpenTelemetry nativo, nova Metrics UI	GA	Sim	Não	Não
Ciclo de vida de 5 anos por major	Política	Sim	Sim	Não informado

O que eu vou testar antes de qualquer upgrade

1. Ir direto para o último patch. A 9.0.2 corrige a CVE-2026-89099 e a 9.0.4 corrige travamentos em step-up e resharding (SERVER-133518, SERVER-133988).
2. Limite de memória por operação. Cada operação agora tem teto de 1 GB ou 20% da memória do servidor, o que for maior. Agregações pesadas que rodavam na 8.x podem falhar com ExceededMemoryLimit. Rode as suas e acompanhe metrics.query.operationsFailedDueToMemoryLimit.
3. Limite de transações abertas. maxConcurrentMultiDocumentTransactions vem com 10.000. Acima disso, novas transações falham com TooManyOpenTransactions.
4. ODMs e syncIndexes(). Com FCV 9.0, o listIndexes passa a reportar collation: { locale: "simple" }, e Mongoose, Doctrine e Beanie podem dropar e recriar índices no startup (SERVER-89953). No Mongoose, as versões 9.10.4 e 8.24.5 resolvem. Nos demais, prefira createIndexes().
5. Métricas renomeadas. metrics.changeStreams.showExpandedEvents virou metrics.changeStreams.option.showExpandedEvents, e houve mudanças em shardingStatistics. Atualize dashboards e alertas.
6. BSON inválido. Agora gera erro. Se algum integrador legado escreve BSON fora do padrão, você vai descobrir no upgrade.
7. Queryable Encryption em preview. Quem usou prefixo, sufixo ou substring no preview da 8.2/8.3 precisa recriar as coleções.
8. Load shedding. Driver deve ser atualizado primeiro, teste em staging, só depois ligar.

Minha leitura

Tem "quem" diga que a 9.0 parece mais uma 8.4 do que uma 9.0, porque não traz uma única feature que muda o jeito de rodar MongoDB. Eu entendo o argumento, mas acho que estão olhaando para o lugar errado. O que a 9.0 entrega (na minha visão) é previsibilidade: o mesmo hardware rendendo mais, o cluster que segura o pico em vez de capotar (salto importante), dado sensível que continua consultável e cinco anos de horizonte para planejar. Para quem opera o MongoDB no dia-a-dia, em produção e ambientes críticos, isso vale mais que um recurso de "simplesmente" apresentável e que gere aplausos durante o evento de lançamento.

O que eu sugiro agora: subir um ambiente de teste no último patch, rodar as agregações mais pesadas contra o novo limite de memória e, se estiver no Atlas, atualizar os drivers para já ter o load shedding como opção. Se não estiver confiante em "fazer sozinho", conte comigo!

No próximo artigo eu entro no Atlas: Atlas Infinite, hardware Gen2 e o que muda na conta. Se quiser ver isso ao vivo, vamos abrir as novidades no próximo MUG São Paulo data e local serão confirmados nos próximos dias.

Fontes

• Press release: MongoDB 9.0 e Atlas Infinite (29/09/2026)
• Everything announced at MongoDB.local NYC 2026 (30/09/2026)
• MongoDB 9.0 release notes
• Intelligent Workload Management: documentação do Atlas
• Blog: Intelligent Workload Management (08/10/2026)
• Queryable Encryption: tipos de consulta e parâmetros
• MongoDB Extension for Hibernate ORM (GitHub)
• Política de versões do MongoDB
• Percona: MongoDB 9.0, more 8.4 than 9.0? (09/10/2026)
• Sessão "Novidades e Roadmap do MongoDB 9.0", MongoDB Champions Summit, Nova York, 28/09/2026

---

Leandro Domingues é Head de Databases e MongoDB Community Champion.