# DocumentDB 8.0: MVU direto reduz risco, não elimina migração O suporte a major version upgrade direto para o Amazon DocumentDB 8.0 é uma melhoria importante para quem ainda carrega clusters 3.6 ou 4.0. Eu trataria o recurso como redução de passos e de exposição, não como desculpa para pular ensaio, testes de compatibilidade e plano de rollback. - URL: https://fernando.moretes.com/blog/documentdb-8-0-mvu-direto-reduz-risco-nao-elimina-migracao-amazon-docum - Markdown: https://fernando.moretes.com/blog/documentdb-8-0-mvu-direto-reduz-risco-nao-elimina-migracao-amazon-docum/article.md?lang=pt - Published: 2026-09-01T19:55:13.642Z - Category: IA & Agentes - Tags: AWS, DocumentDB, MongoDB, Databases, Modernization, Reliability, Cost, Security - Reading time: 8 min - Source: [Amazon DocumentDB now supports direct major version upgrades to version 8.0](https://aws.amazon.com/about-aws/whats-new/2026/08/documentdb-major-version-upgrade-8-0/) --- A notícia de 31 de agosto de 2026 parece pequena: o Amazon DocumentDB agora permite major version upgrades in-place de clusters 3.6 e 4.0 diretamente para a versão 8.0, preservando dados, configurações e endpoints. Para mim, em ambientes financeiros, ela é maior do que uma conveniência operacional. Ela muda a economia de risco de uma modernização atrasada: menos saltos, menos janelas, menos inventário temporário e uma chance mais objetiva de sair de versões antigas sem transformar a migração em um programa paralelo de vários meses. Mas eu não confundiria o botão de upgrade com uma estratégia de upgrade. A versão 8.0 traz TLS 1.2 obrigatório, novo planner, collation, views, Text Index V2, compressão Zstd e diferenças de comportamento que podem expor suposições antigas em consultas, índices e drivers. O ganho está em industrializar a passagem, não em tratá-la como manutenção trivial. ## O que eu mediria antes de aprovar - **3.6/4.0 -> 8.0** — Caminho anunciado. A página What's New informa upgrade direto para 8.0 a partir de 3.6 e 4.0; eu validaria a versão-alvo disponível por Região via API antes da mudança. - **TLS 1.2+** — Barreira de compatibilidade. DocumentDB 8.0 não aceita TLS 1.0/1.1; qualquer cliente antigo precisa ser identificado antes da janela. - **256 TiB** — Limite de cluster no 8.0. A documentação de quotas lista 256 TiB para clusters e databases na versão 8.0 ou posterior, contra 128 TiB em versões anteriores. ## O que mudou de verdade Eu vejo este lançamento como uma peça de descompressão para organizações que ficaram presas em versões antigas do DocumentDB por dependências de aplicação, medo de indisponibilidade ou backlog regulatório. Antes, o caminho mental típico era tratar a modernização como uma sequência: inventariar, corrigir clientes, ensaiar upgrade intermediário, estabilizar, repetir, e só então chegar à versão desejada. Quando há dezenas de clusters por domínio de negócio, essa coreografia multiplica CABs, evidências de mudança, testes regressivos e períodos de convivência entre engines. O upgrade direto para 8.0 reduz principalmente o número de estados intermediários que precisam ser governados. Em vez de manter uma versão intermediária apenas como degrau, eu posso organizar uma transição orientada por evidências: clone, ensaio, validação de workload realista, janela de corte e observabilidade pós-upgrade. O cluster continua sendo o mesmo endpoint e o mesmo storage lógico, o que diminui alterações de DNS, secret rotation e reconfiguração de aplicações. O ponto crítico é que “in-place” não significa “sem downtime”. A documentação de MVU deixa claro que o cluster fica indisponível durante o upgrade e pode reiniciar múltiplas vezes. Em sistemas financeiros, isso coloca a decisão no campo de SLO, calendário de negócio e reversibilidade operacional, não apenas no campo de compatibilidade de engine. ## Onde o 8.0 realmente ajuda O motivo técnico para mirar 8.0 não é apenas sair de suporte estendido. A versão traz compatibilidade com drivers das APIs MongoDB 6.0, 7.0 e 8.0, Planner Version 3, collation, views, Text Index V2, novos operadores de agregação e compressão Zstd. A AWS também publicou ganhos de desempenho de até 7x em latência de pipelines de agregação e até 5x em taxa de compressão em cenários específicos. Eu trataria esses números como teto observado, não como promessa universal; ainda assim, eles indicam onde a versão tende a pagar a conta. Workloads com leitura pesada, agregações recorrentes, buscas textuais simples, documentos pequenos e padrões de consulta bem indexados são bons candidatos. Em uma plataforma de atendimento, antifraude ou onboarding digital, por exemplo, a combinação de compressão melhor e planner mais eficiente pode reduzir pressão de I/O e estabilizar p95/p99 quando há consultas de enriquecimento ou painéis operacionais lendo coleções grandes. Também há ganhos de arquitetura. Views ajudam a encapsular projeções canônicas sem espalhar lógica por serviços. Collation reduz soluções caseiras para ordenação e comparação textual. Zstd pode melhorar custo de storage e I/O, mas deve ser habilitado com medição, porque compressão troca CPU por eficiência de armazenamento. Em banco operacional, essa troca precisa aparecer em métricas, não em convicção. ## Modelo operacional que eu usaria para o upgrade O centro da decisão não é o comando de upgrade; é o circuito de evidência antes, durante e depois da janela. ### 🧭 Governance and readiness - Cluster inventory 3.6/4.0, owners, SLO (ci) - Compatibility review TLS, drivers, indexes (security) - Change record rollback and evidence (ci) ### 🟧 AWS validation lane - DocumentDB clone same instance count (data) - Replay tests queries, jobs, APIs (compute) - CloudWatch + logs CPU, I/O, cursors, p99 (data) ### 🟦 Production lane - Manual snapshot pre-upgrade restore point (storage) - In-place MVU 3.6/4.0 to 8.0 (data) - Index metadata refresh wait for completion (data) - Applications feature flags, retry budget (compute) ### Fluxos - inventory -> compat: classifica risco - compat -> clone: define ensaio - clone -> tests: executa carga representativa - tests -> metrics: compara baseline - metrics -> cab: gera evidência - cab -> snapshot: autoriza janela - snapshot -> mvu: ponto de retorno - mvu -> refresh: pós-upgrade - refresh -> apps: retoma tráfego - apps -> metrics: observa regressões ## Os limites que eu não ignoraria O primeiro limite é documental e operacional. Ao pesquisar em 1 de setembro de 2026, encontrei a página What's New afirmando upgrade direto de 3.6 e 4.0 para 8.0, enquanto a página de MVU aberta ainda mostrava uma tabela com 3.6/4.0 para 5.0 e 5.0 para 8.0, além de uma nota dizendo que não havia caminho direto. Eu confiaria no anúncio mais novo como direção do serviço, mas não aprovaria produção sem confirmar no próprio ambiente com `describe-db-engine-versions`, console da Região alvo e, se necessário, suporte AWS. Essa divergência é exatamente o tipo de detalhe que derruba uma janela bem planejada. O segundo limite é compatibilidade. DocumentDB não é MongoDB upstream; é compatível com API, com diferenças funcionais publicadas. Um upgrade de engine pode mudar planejamento de consulta, comportamento de índice textual, collation padrão em novos objetos e exigência de TLS. Aplicações antigas podem ter drivers que “funcionam” em teste feliz, mas falham sob pool exhaustion, renegociação TLS, serialização BSON ou timeouts agressivos. O terceiro limite é estado pós-upgrade. A documentação menciona refresh de metadados de índice após MVU, normalmente em minutos, mas podendo levar até duas horas, com orientação para acionar suporte se passar de três horas. Eu não marcaria a janela como concluída no momento em que o cluster volta para `available`; só encerraria após consultas críticas, jobs batch e sinais de capacidade estabilizarem. ## Onde o recurso brilha - Ele reduz a quantidade de janelas de mudança para clusters antigos, o que é valioso quando cada indisponibilidade exige comunicação, evidência regulatória e plano de reversão aprovado. - Ele preserva endpoints, tags, storage e configurações de cluster, diminuindo alterações em aplicações, secrets, runbooks e dashboards de observabilidade. - Ele cria uma ponte mais curta para recursos de 8.0 como Planner Version 3, Zstd, collation, views, Text Index V2 e drivers mais atuais. - Ele torna mais fácil justificar financeiramente a saída do DocumentDB 3.6, que entrou em suporte estendido em 2026 e passa a carregar prêmio adicional de custo. - Ele favorece programas de modernização por frota: inventário, ondas, automação de prechecks, evidência padronizada e governança por domínio. > **A parte perigosa é a confiança excessiva:** Eu não executaria este upgrade como alteração isolada de banco. O caminho direto encurta a jornada, mas o cluster ainda fica indisponível, não há downgrade in-place, clientes precisam suportar TLS 1.2 ou superior, e clusters globais ou elásticos têm restrições próprias de upgrade. Para produção crítica, o restore de snapshot para um novo cluster é plano de recuperação, não botão mágico de rollback; ele muda endpoint, tempo de retorno e operação de reconexão das aplicações. ## Como eu desenharia a janela em ambiente financeiro Minha abordagem começaria por classificação de criticidade. Um cluster que atende leitura de catálogo interno não merece o mesmo processo de um cluster que participa de antifraude, onboarding, consentimento Open Finance ou experiência transacional. Para cada cluster crítico, eu levantaria dono, RTO, RPO, volume, número de coleções, número de índices, drivers por aplicação, versões de runtime, uso de change streams, transações, índices parciais, buscas textuais e integrações com Lambda, Glue, MSK ou jobs noturnos. Depois eu criaria um clone do cluster, com contagem de instâncias igual ao destino sempre que possível, para estimar duração real e capturar regressões. O teste precisa ir além de health check: replay de consultas representativas, explain plans onde fizer sentido, jobs batch, APIs com pool de conexão realista, failover controlado fora da janela e comparação de p95/p99, CPU, I/O, FreeableMemory, DatabaseConnections, DatabaseCursors e logs de queries lentas. Na janela, eu congelaria deploys que possam alterar o padrão de acesso, reduziria concorrência de jobs não essenciais, confirmaria snapshot manual e aplicaria o upgrade com parâmetro de engine e parameter group explícitos. Depois do retorno, eu manteria modo de observação: não escalar, não reiniciar e não forçar failover enquanto o refresh de metadados de índice não terminar. A evidência final seria funcional e operacional: transações de negócio, latência, erros, filas, jobs e dashboards. ## Decisão prática: upgrade direto, dois saltos ou migração paralela | Critério | Opção | Quando faz sentido | Risco principal | | --- | --- | --- | --- | | MVU direto para 8.0 | Minha opção preferida quando a Região e o cluster confirmam o caminho, os drivers já foram testados, e a janela de indisponibilidade é aceitável. | Concentra mais mudança em uma janela só; qualquer incompatibilidade aparece mais perto do corte. | — | | MVU em dois saltos | Útil quando a documentação, a Região ou o suporte ainda indicam caminho intermediário, ou quando a organização quer reduzir delta funcional por etapa. | Mais janelas, mais tempo em estado transitório e mais custo de coordenação. | — | | Migração paralela com DMS ou aplicação | Boa para clusters que não toleram indisponibilidade de MVU, precisam redesenhar modelo de dados ou querem validar 8.0 com tráfego em sombra. | Duplica complexidade: sincronização, dual-write ou CDC, reconciliação, cutover e possível divergência de dados. | — | ## Roteiro de adoção que eu aprovaria 1. **Inventariar por risco, não por conta AWS** — Agrupe clusters por criticidade, RTO/RPO, Região, versão, instância, uso de transações, change streams, índices e dependências de aplicação. O plano por frota deve expor quem aceita downtime e quem precisa de migração paralela. 2. **Validar caminho e pré-requisitos na Região alvo** — Use console e `aws docdb describe-db-engine-versions` para confirmar engine 8.0 disponível como destino, aplique OS patches pendentes, revise instance families antigas, configure parameter group alvo e trate índices parciais ou nomes de coleção problemáticos antes da janela. 3. **Ensaiar em clone com carga representativa** — Clone o volume, mantenha contagem de instâncias próxima da produção, execute o upgrade, rode queries reais, jobs batch e APIs com pools semelhantes aos de produção. Compare baseline de latência, CPU, I/O, conexões, cursores e logs lentos. 4. **Preparar rollback honesto** — Snapshot manual é obrigatório, mas restauração cria novo cluster. Documente DNS, secrets, security groups, parameter groups, tempo estimado de restauração, critério de abortar e quem tem autoridade para decidir durante a madrugada. 5. **Operar o pós-upgrade como estabilização** — Espere o refresh de metadados de índice, valide transações críticas, reabilite jobs em ondas, acompanhe p95/p99 e erro por endpoint, e só depois considere habilitar novos recursos como Zstd em coleções existentes ou uso de views em aplicações. ## Falhas prováveis e como eu as mitigaria A falha mais comum em upgrades de banco não é o serviço falhar; é a aplicação revelar uma dependência invisível. Eu procuraria clientes Java, Node.js, Python ou .NET antigos, imagens de container sem CA bundle atualizado, `tlsAllowInvalidCertificates` usado em ambientes legados, timeouts rígidos e pools com reconexão agressiva. A partir do 8.0, TLS 1.2 ou superior é requisito; isso precisa virar teste automatizado, não checklist manual. Em dados, eu olharia para índices e consultas. Índices herdados de 3.6/4.0 podem funcionar, mas não entregar o plano esperado até reconstrução ou refresh. A documentação recomenda considerar `reIndex` após upgrades de 3.6/4.0 para desempenho ideal, com custo adicional de I/O. Eu não faria isso às cegas em produção; priorizaria coleções que aparecem em top queries, dashboards críticos e jobs com SLA. Em operação, eu trataria o evento de upgrade como indisponibilidade controlada. API Gateway, ALB, Lambda, EKS e workers precisam falhar de forma previsível: circuit breakers, mensagens de manutenção, filas com DLQ quando aplicável, retry com jitter e idempotência em comandos de escrita. Se a aplicação fica tentando escrever sem limite durante a janela, o banco volta e recebe uma tempestade artificial. A melhor arquitetura aqui é aquela que sabe ficar quieta quando a dependência crítica está declaradamente indisponível. ## Anti-padrões que eu barraria - Executar o MVU direto sem clone, sem estimativa de duração e sem replay das consultas que sustentam os SLOs do negócio. - Usar o retorno para `available` como único critério de sucesso, ignorando refresh de metadados de índice, latência p99, erros de driver e backlog de jobs. - Misturar upgrade de engine com mudança de modelo de dados, troca de driver, novo padrão de compressão e refatoração de aplicação na mesma janela. - Prometer rollback rápido sem ensaiar restore de snapshot para novo cluster, atualização de secrets, DNS ou configuração das aplicações consumidoras. - Aprovar a mudança apenas porque o suporte estendido custa mais, sem quantificar downtime, risco de incompatibilidade e custo de validação. ## Leitura Well-Architected - **security**: A exigência de TLS 1.2+ é uma oportunidade para remover clientes inseguros, revisar rotação de certificados, validar Secrets Manager e restringir IAM com ações `docdb:ModifyDBCluster`, `docdb:CreateDBClusterSnapshot` e escopo por ARN/Tag quando possível. - **reliability**: A arquitetura precisa declarar a indisponibilidade: manutenção comunicada, filas tolerantes, idempotência em escritas, snapshot manual, runbook de restauração e critérios objetivos para abortar ou seguir. - **performance**: Planner Version 3, Text Index V2 e Zstd podem melhorar latência e eficiência, mas só contam após comparação com baseline por consulta, cardinalidade de índice, tamanho de documento e comportamento de agregações reais. > **Minha curadoria:** Eu usaria o MVU direto para 8.0, mas só depois de provar o caminho em clone e resolver a divergência momentânea entre anúncio e documentação operacional. Em ambiente financeiro, reduzir passos é bom; reduzir evidência é perigoso. A lição que aprendi em modernizações de banco é simples: o risco raramente está no comando administrado, está nas dependências silenciosas que nunca foram testadas sob falha controlada. Eu trataria esta novidade como chance de encerrar dívida técnica antiga com disciplina, não como atalho. ## Referências verificadas - [AWS What's New - Amazon DocumentDB now supports direct major version upgrades to version 8.0](https://aws.amazon.com/about-aws/whats-new/2026/08/documentdb-major-version-upgrade-8-0/) - [Amazon DocumentDB in-place major version upgrade documentation](https://docs.aws.amazon.com/documentdb/latest/devguide/docdb-mvu.html) - [Amazon DocumentDB engine version support dates](https://docs.aws.amazon.com/documentdb/latest/devguide/docdb-version-support-dates.html) - [Amazon DocumentDB features and configurations](https://docs.aws.amazon.com/documentdb/latest/devguide/docdb-engine-version-supportability.html) - [Amazon DocumentDB quotas](https://docs.aws.amazon.com/documentdb/latest/devguide/limits.html) - [Announcing Amazon DocumentDB 8.0](https://aws.amazon.com/about-aws/whats-new/2025/11/documentdb-8-o/) - [AWS Database Blog - Turbocharge your applications with Amazon DocumentDB 8.0](https://aws.amazon.com/blogs/database/turbocharge-your-applications-with-amazon-documentdb-8-0/) - [Amazon DocumentDB Extended Support charges](https://docs.aws.amazon.com/documentdb/latest/devguide/support-charges.html) ## Veredito Minha nota é 8/10. O upgrade direto para o DocumentDB 8.0 é uma capacidade muito bem-vinda para reduzir risco acumulado, custo de suporte estendido e complexidade de programas de modernização. Eu recomendo adotá-lo para clusters 3.6 e 4.0 que possam tolerar uma janela de indisponibilidade, desde que o caminho seja confirmado na Região, os drivers passem por teste real, exista snapshot manual, e o pós-upgrade seja acompanhado até estabilização de índices e latência. Para sistemas sem janela aceitável ou com dependências pouco conhecidas, eu ainda escolheria migração paralela ou ondas menores. O serviço melhorou; a responsabilidade arquitetural continua sendo provar que a aplicação aguenta a mudança.