DynamoDB: o banco NoSQL serverless da AWS, e quando ele não é a escolha certa

Quem decide onde um dado vai morar na AWS esbarra cedo ou tarde no DynamoDB. Ele é o banco NoSQL serverless da AWS, lançado em 2012, e a documentação oficial da AWS descreve o serviço como projetado para entregar performance de milissegundos de um único dígito (single-digit millisecond) em qualquer escala, do protótipo com 10 usuários ao sistema com 100 milhões.

A mesma documentação afirma que, em eventos como a Prime Day, o DynamoDB sustenta propriedades de tráfego altíssimo da própria Amazon, incluindo Alexa, os sites da Amazon.com e os centros de fulfillment. Separadamente, a documentação cita que o serviço atende continuamente centenas de clientes que operam tabelas com pico de tráfego acima de meio milhão de requisições por segundo.

Esse não é um detalhe de marketing: é o motivo de o DynamoDB ter virado o banco padrão de quem constrói aplicação serverless na AWS. Mas "padrão" não é sinônimo de "serve para tudo". A escolha certa depende do padrão de acesso aos dados, não da popularidade do serviço.

Serverless de verdade, inclusive na cobrança

No DynamoDB você não provisiona servidor, não aplica patch, não gerencia versão (major, minor ou patch) e não tem janela de manutenção. O serviço tem dois modos de capacidade: on-demand, com cobrança por requisição de leitura e escrita, e provisioned, em que você reserva RCU e WCU (Read/Write Capacity Units). No modo on-demand, a tabela escala para zero quando não há tráfego, sem cold start e sem custo de throughput parado.

Isso muda a conta de quem hoje opera um RDS ou um cluster self-managed: não existe mais a decisão de dimensionar instância para o pico e pagar por ela o mês inteiro. O trade-off é que on-demand custa mais por requisição do que provisioned bem dimensionado, então workload previsível e estável ainda compensa capacidade reservada com auto scaling.

O que faz o DynamoDB ser NoSQL, na prática

A documentação é direta num ponto que costuma pegar quem vem do mundo relacional: o DynamoDB não tem operador JOIN. A recomendação oficial é desnormalizar o modelo de dados para reduzir round-trips e poder de processamento necessários para responder às queries. Isso significa modelar a tabela em volta do acesso que a aplicação vai fazer, não em volta da entidade de negócio.

Na prática, quem desenha tabela DynamoDB define a chave de partição e a chave de ordenação (partition key e sort key) pensando primeiro em quais Query a aplicação vai rodar, e só depois em como os dados se relacionam entre si. Para alcançar outros atributos além da chave primária, o serviço oferece índices secundários globais e locais (GSI e LSI), que dão acesso alternativo aos mesmos itens sem duplicar tabela inteira. Mesmo sendo NoSQL, o DynamoDB sustenta consistência forte de leitura e transações ACID, o que remove o argumento antigo de que NoSQL implica abrir mão de consistência.

Onde a AWS diz que o DynamoDB resolve

A própria documentação lista três famílias de caso de uso como as mais fortes para o serviço:

• Serviços financeiros: trading, roteamento de ordens, geração de token e livros-razão de transação, usando DynamoDB global tables para responder com leitura e escrita locais em cada região, e transações ACID para garantir atomicidade entre múltiplas tabelas numa única requisição.
• Jogos: estado de partida, dados de jogador, histórico de sessão e leaderboard, aproveitando o scale-to-zero sem cold start para absorver pico de lançamento sem pagar ocioso fora dele.
• Streaming de mídia: índice de metadado de conteúdo, watchlist, bookmarking e geração de recomendação a partir de bilhões de eventos diários de cliente.

O fio comum entre os três é o mesmo: performance consistente em milissegundos, não importa se a tabela tem 10 itens ou 200 TB (a AWS cita centenas de clientes acima desse volume).

Transações, streams e o que conecta o DynamoDB ao resto da stack

O DynamoDB expõe mudança de dado item a item quase em tempo real por dois modelos: DynamoDB Streams e Kinesis Data Streams for DynamoDB. Isso permite acoplar um trigger de AWS Lambda que reage a toda inserção, atualização ou remoção de item, viabilizando arquitetura orientada a evento sem polling.

Para quem precisa tirar o dado operacional do DynamoDB e colocar em analytics, existem integrações zero-ETL com Amazon Redshift e com OpenSearch Ingestion, descritas na documentação como sem impacto na carga de produção. Também dá para exportar e importar tabela inteira (ou só o delta de um período) direto para o Amazon S3, útil para alimentar pipeline de machine learning sem duplicar lógica de extração.

Quando a latência de milissegundo do DynamoDB ainda não é suficiente, entra o DynamoDB Accelerator (DAX): um cache gerenciado em memória que a documentação credita com até 10 vezes de ganho de performance, levando leitura de milissegundo para microssegundo, sem você gerenciar invalidação de cache ou cluster.

Segurança e resiliência que vêm por padrão

Todo dado em repouso no DynamoDB é criptografado por padrão, com chave gerenciada pela AWS sem custo adicional (ou chave própria via AWS KMS, se a política de compliance exigir). O acesso é inteiramente controlado por IAM: não existe usuário e senha de banco, o que elimina rotina de rotação de senha como superfície de risco.

Para recuperação de desastre, o serviço replica automaticamente entre três zonas de disponibilidade com SLA de 99,99%, e o point-in-time recovery permite restaurar a tabela para qualquer segundo dentro de uma janela configurável de 1 a 35 dias, sem consumir capacidade provisionada. Quem precisa de resiliência multi-região tem o global tables, com replicação multi-ativa e SLA de 99,999%, sem failover manual porque não existe tabela primária.

Quando o DynamoDB não é a resposta

Nem todo caso de uso pede um banco chave-valor sem JOIN. A pergunta que todo arquiteto de dados na AWS acaba fazendo é: "esse padrão de acesso realmente pede DynamoDB?". A resposta começa pelo padrão de consulta que a aplicação já faz, não pela popularidade do serviço.

Se a aplicação precisa de JOIN recorrente entre muitas entidades, consulta ad hoc sobre atributo não indexado, ou um time que já domina SQL e não quer reescrever a camada de acesso a dado, o caminho mais barato em esforço costuma ser um banco relacional gerenciado (RDS ou Aurora), não forçar o modelo em um banco chave-valor.

Custo para começar a testar

A AWS mantém o DynamoDB no always free tier: 25 GB de armazenamento e 25 unidades de capacidade provisionada de leitura e escrita (RCU/WCU), suficientes, segundo a documentação, para cerca de 200 milhões de requisições por mês. É espaço de sobra para rodar os tutoriais oficiais de criação e consulta de tabela NoSQL sem sair do free tier, e validar na prática se o padrão de acesso da sua aplicação realmente pede DynamoDB antes de comprometer a modelagem definitiva.

Fonte: Documentação do Amazon DynamoDB