DocumentDB 8.0: MVU direto reduz risco, não elimina migração

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.

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.

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.

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.

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.