DynamoDB na Prática: Quando Trocar o Banco Relacional por NoSQL

Um banco de dados relacional bem projetado começa a doer de um jeito específico quando a aplicação escala: consultas que exigiam três joins simples passam a exigir dez, os índices multiplicam para compensar, e o time de infraestrutura vive ajustando o tamanho da instância do RDS para aguentar o pico de tráfego. O Amazon DynamoDB resolve esse problema de um jeito radical: em vez de escalar verticalmente uma instância única, ele distribui os dados automaticamente entre partições, e entrega respostas em milissegundos de forma consistente, esteja a tabela com cem ou cem milhões de itens. A troca é real, mas não é gratuita — sai o SQL e as consultas ad hoc, entra a obrigação de desenhar o acesso aos dados antes de desenhar a tabela. Este guia explica como o DynamoDB funciona na prática, quando a migração para NoSQL compensa e quando ela só cria trabalho.

O Que É o Amazon DynamoDB e o Modelo de Dados Chave-Valor/Documento

O DynamoDB é um banco de dados NoSQL totalmente gerenciado, do tipo chave-valor e documento, feito para aplicações que precisam de latência previsível em qualquer escala. A AWS cuida de provisionamento de servidor, patch, replicação e particionamento — o que sobra para a equipe é modelar os dados e definir as chaves de acesso.

A diferença de raiz para o modelo relacional está na unidade de armazenamento. Uma tabela do DynamoDB guarda itens, e cada item é um conjunto de atributos — pense num documento JSON flexível, não numa linha rígida de colunas fixas. Dois itens da mesma tabela podem ter atributos completamente diferentes, desde que compartilhem a chave primária. Não existe schema de colunas para alterar quando um novo campo aparece; existe, isso sim, um limite de tamanho por item: segundo a documentação oficial da AWS, o tamanho máximo de um item individual é 400 KB, contando nomes e valores de atributos.

Essa flexibilidade tem um preço que pega muita equipe de surpresa: o DynamoDB não tem joins, não tem uma linguagem de consulta ad hoc equivalente ao SQL para relacionar tabelas, e não foi feito para perguntas que só existem na hora da análise. Ele foi feito para o oposto — para responder perguntas conhecidas de antemão, muito rápido, em qualquer volume.

Como Funciona: Partition Key, Sort Key e Índices

Toda tabela do DynamoDB tem uma chave primária, que pode ser de dois formatos:

• Chave primária simples: só a partition key (chave de partição). É o valor que o DynamoDB usa para decidir em qual partição física o item vai morar — através de uma função de hash interna. Duas contas de cliente com IDs diferentes, por exemplo, quase certamente caem em partições diferentes.
• Chave primária composta: partition key + sort key (chave de classificação). Todos os itens que compartilham a mesma partition key ficam na mesma partição, ordenados pela sort key. É o desenho clássico para guardar, por exemplo, todos os pedidos de um cliente (ClienteId como partition key, DataPedido como sort key) e buscar um intervalo de datas com uma única consulta eficiente.

A escolha da partition key é a decisão de modelagem mais importante do projeto. Uma partition key com baixa cardinalidade — poucos valores distintos, ou um valor concentrando desproporcionalmente o tráfego — cria uma "hot partition": uma fatia dos dados recebendo tráfego muito acima da média, enquanto o resto da tabela fica ocioso. É o erro mais comum de quem chega do relacional e tenta usar um campo tipo status ("ativo", "inativo") como partition key: poucos valores possíveis, tráfego concentrado, throttling na certa.

Para consultas que não seguem a chave primária, o DynamoDB oferece dois tipos de índice secundário:

• Local Secondary Index (LSI): mesma partition key da tabela, sort key diferente. Precisa ser criado junto com a tabela e tem limite de 5 por tabela.
• Global Secondary Index (GSI): partition key e sort key completamente diferentes da tabela original — na prática, uma segunda forma de consultar os mesmos dados. Pode ser criado a qualquer momento, com limite padrão de 20 por tabela, e tem capacidade de leitura/escrita provisionada separadamente da tabela principal.

A regra prática que resume a modelagem no DynamoDB, e que inverte a lógica do relacional: desenhe as consultas de acesso primeiro, a estrutura da tabela depois. No modelo relacional normaliza-se os dados e as consultas se adaptam depois, via joins. No DynamoDB, cada padrão de acesso não coberto pela chave primária ou por um GSI é uma consulta lenta ou impossível — não dá para "resolver com um join" depois que a tabela já está em produção.

Modelos de Capacidade: On-Demand vs. Provisioned

O DynamoDB oferece dois modos de cobrança e escala, e a escolha entre eles é uma decisão de arquitetura, não só de custo.

No modo on-demand, a tabela escala automaticamente e a cobrança é por requisição consumida — sem planejamento de capacidade, sem política de auto scaling para configurar. É o modo padrão recomendado pela própria AWS para a maioria das cargas de trabalho, principalmente as que têm tráfego imprevisível ou picos difíceis de prever (uma campanha de marketing, um lançamento de produto).

No modo provisioned, a equipe declara quantas unidades de capacidade de leitura (RCU) e escrita (WCU) espera consumir por segundo, e paga por hora com base no que foi provisionado — não no que foi de fato consumido. Compensa quando o tráfego é estável e previsível, porque o custo por unidade de capacidade é sensivelmente menor que o equivalente em requisições on-demand. É possível somar auto scaling ao modo provisioned para ajustar a capacidade dentro de limites definidos, mas a reação não é instantânea como no on-demand puro.

Não existe modo "melhor" de forma absoluta. Um sistema de e-commerce sazonal, com pico concentrado em datas específicas, tende a sair mais barato em on-demand — a alternativa seria provisionar para o pico e pagar ocioso o resto do ano, o mesmo tipo de desperdício que uma prática de FinOps na AWS existe para capturar. Já um sistema interno com volume estável de transações, monitorado de perto, tende a economizar no modo provisioned com auto scaling bem calibrado.

DynamoDB vs. Banco de Dados Relacional: o Que Muda

A tabela abaixo resume as diferenças que mais pesam na decisão de arquitetura:

A linha mais importante da tabela para quem decide é a de modelagem. Trocar de relacional para DynamoDB não é trocar o motor mantendo o mesmo desenho de tabelas — é redesenhar o sistema em torno de como os dados são lidos, o que costuma exigir reescrever a camada de acesso a dados da aplicação inteira, não só migrar o schema.

DynamoDB Streams e Global Tables: Casos de Uso Avançados

Dois recursos ampliam o que o DynamoDB resolve sozinho, sem depender de um pipeline de dados separado.

O DynamoDB Streams captura, em quase tempo real, um registro ordenado de cada modificação feita na tabela — criação, atualização ou exclusão de item — e mantém esse log disponível por 24 horas. Cada modificação pode incluir a imagem do item antes e/ou depois da mudança, conforme a configuração escolhida. O uso mais comum é como gatilho para uma função do AWS Lambda: toda alteração num pedido dispara automaticamente um processo de notificação, atualização de índice de busca, ou sincronização com outro sistema — sem que a aplicação precise implementar esse fluxo manualmente. É o tipo de mecanismo de captura de mudança de dados que só faz sentido operacionalmente dentro de uma arquitetura serverless, onde Lambda e DynamoDB já compartilham o mesmo modelo de escala sob demanda.

As Global Tables replicam uma tabela automaticamente entre regiões da AWS, sem que a equipe precise construir a própria solução de replicação. Qualquer réplica pode atender leituras e escritas — é um modelo multi-ativo, não um esquema tradicional de primário/standby. A AWS oferece dois modos de consistência: consistência eventual multi-região (MREC), o padrão, e consistência forte multi-região (MRSC), para quem não pode tolerar uma janela de divergência entre regiões. É a peça que sustenta aplicações globais com baixa latência local em cada região e continuidade de negócio com RPO próximo de zero.

Para cargas de leitura que exigem tempo de resposta ainda menor que os milissegundos padrão do DynamoDB, existe o DAX (DynamoDB Accelerator), um cache gerenciado, compatível com a própria API do DynamoDB, que reduz a latência de leituras eventualmente consistentes para a faixa de microssegundos. A documentação da AWS é direta sobre quando ele não serve: aplicações que exigem leitura fortemente consistente, cargas majoritariamente de escrita, ou padrões de leitura sem repetição — DAX funciona melhor com taxa de acerto de cache acima de 90%, e não ajuda quando cada leitura busca um item diferente.

Quanto Custa Rodar o DynamoDB na Prática

No modo on-demand, a página oficial de preços da AWS publica, para a região US East (N. Virginia) e a classe de tabela padrão, US$ 0,125 por milhão de leituras e US$ 0,625 por milhão de escritas — a região de São Paulo tem tabela própria, então use esses números só como referência de proporção, não como estimativa direta para o Brasil.

A proporção entre os dois números já ensina algo prático: escrever custa cerca de cinco vezes mais que ler, no on-demand. Um desenho de tabela que grava o mesmo dado em múltiplos formatos para acelerar diferentes consultas — uma técnica legítima de modelagem em NoSQL, chamada de desnormalização — precisa considerar esse custo de escrita multiplicada, não só o ganho de leitura.

No modo provisioned, o custo é por hora de capacidade reservada (RCU/WCU), independente do uso — o mesmo princípio de uma instância de banco relacional ociosa que continua sendo cobrada. A diferença é que, no DynamoDB, dá para provisionar por tabela e por índice, com granularidade muito mais fina do que redimensionar uma instância inteira do RDS.

O item mais fácil de perder de vista na conta é o das GSIs: cada índice secundário global tem sua própria capacidade provisionada (ou consumo on-demand), separada da tabela principal. Uma tabela com três GSIs pode gerar quatro linhas de cobrança diferentes — e é comum que a equipe monitore só a tabela e não perceba o crescimento de custo vindo dos índices. Acompanhar essas métricas junto com o resto da conta AWS é o tipo de disciplina que se encaixa numa rotina de análise de custos AWS e de observabilidade contínua com CloudWatch.

Quando Faz Sentido Migrar do Relacional para o DynamoDB — e Quando NÃO Faz

O DynamoDB não é um substituto universal para o banco relacional, e tratá-lo como tal é o erro mais caro que uma equipe pode cometer — porque o custo de modelar errado só aparece depois que a aplicação já está em produção e os padrões de acesso mudaram.

Faz sentido migrar quando:

• Os padrões de acesso são conhecidos e estáveis — a aplicação consulta os dados sempre pelas mesmas chaves (ID do usuário, ID da sessão, ID do pedido), sem necessidade de consultas ad hoc.
• Há necessidade real de escala horizontal e latência previsível em milhões de requisições — catálogos de sessão, carrinho de compras, dados de IoT, leaderboards de jogos, APIs de alto tráfego.
• A carga de trabalho tem picos difíceis de prever, e o modelo de cobrança por requisição do on-demand evita pagar por capacidade ociosa.
• A equipe está construindo algo novo em arquitetura serverless, onde a integração nativa com Lambda e a ausência de gestão de instância já são parte do desenho.

Não faz sentido migrar quando:

• O sistema depende de relatórios ad hoc, BI ou consultas analíticas variadas — é exatamente o caso onde SQL e joins vencem qualquer modelagem NoSQL.
• Há regras de negócio relacionais complexas, com múltiplas entidades interdependentes e transações que cruzam muitas tabelas de formas imprevisíveis — sistemas financeiros e ERPs tradicionalmente se encaixam aqui.
• A equipe não tem capacidade de investir tempo em modelar os padrões de acesso antes de escrever código — migrar sem esse trabalho prévio custa mais caro do que manter o relacional.
• O volume e a complexidade da aplicação não justificam a escala que o DynamoDB entrega — para a maioria das PMEs com carga de trabalho tradicional, um RDS ou Aurora bem dimensionado continua sendo a opção mais simples de operar e de manter.

Um padrão que funciona bem na prática, e que evita a decisão de tudo-ou-nada: manter o sistema principal no relacional e usar o DynamoDB de forma pontual, para os componentes específicos que precisam da escala e da latência que ele entrega — um serviço de sessão, um contador de eventos em tempo real, um catálogo de produtos consultado por chave. Não é preciso escolher um único banco para a empresa inteira.

Tendências: DynamoDB, IA e Arquiteturas Modernas

A adoção de aplicações de inteligência artificial vem puxando um uso crescente do DynamoDB para além do caso de uso tradicional: guardar histórico de conversas de agentes de IA, estado de sessão de assistentes virtuais e metadados de embeddings, todos padrões de acesso simples por chave que se encaixam bem no modelo do banco. A própria AWS já expandiu o DynamoDB com suporte a índices vetoriais para busca por similaridade — um sinal de que o serviço está sendo posicionado também como peça de infraestrutura para aplicações de IA, não só para sistemas transacionais tradicionais.

Do lado operacional, a tendência é a consolidação de arquiteturas totalmente serverless, onde DynamoDB, Lambda e API Gateway formam o núcleo de sistemas que escalam automaticamente e não exigem gestão de servidor em nenhuma camada — uma proposta de valor que vem crescendo em empresas de porte médio que não têm equipe de infraestrutura dedicada a operar bancos de dados 24 horas.

Perguntas Frequentes sobre Amazon DynamoDB

O DynamoDB substitui completamente o banco relacional?

Não. O DynamoDB resolve bem um conjunto específico de problemas — alta escala, baixa latência, padrões de acesso conhecidos — mas não tem joins nativos nem suporte a consultas ad hoc complexas. Sistemas com regras de negócio relacionais, relatórios analíticos variados ou necessidade de SQL completo continuam mais bem atendidos por um banco relacional como RDS ou Aurora.

Qual é o tamanho máximo de um item no DynamoDB?

400 KB, incluindo nomes e valores de todos os atributos do item. Itens maiores que isso — como arquivos, imagens ou documentos grandes — devem ser armazenados no Amazon S3, com apenas uma referência (a chave do objeto) guardada no item do DynamoDB.

Qual modo de capacidade devo escolher: on-demand ou provisioned?

On-demand é o padrão recomendado pela própria AWS para a maioria das cargas, principalmente as com tráfego imprevisível — não exige planejamento de capacidade. Provisioned costuma sair mais barato para cargas estáveis e previsíveis, mas exige acompanhar métricas de consumo e, se necessário, configurar auto scaling.

O que acontece se eu escolher uma partition key ruim?

O tráfego se concentra numa fração das partições físicas — uma "hot partition" — enquanto o resto da tabela fica ocioso, gerando throttling mesmo com capacidade total suficiente na tabela. É o erro de modelagem mais comum entre equipes que migram do relacional sem redesenhar os padrões de acesso primeiro.

O DynamoDB tem transações como um banco relacional?

Sim, de forma limitada: as operações TransactWriteItems e TransactGetItems garantem atomicidade ACID para até 100 itens numa mesma transação, dentro de uma ou mais tabelas. Não é uma transação com o mesmo alcance de um banco relacional multi-tabela complexo, mas cobre a maioria dos casos práticos de consistência que uma aplicação transacional exige.

DynamoDB Streams substitui uma ferramenta de ETL ou pipeline de dados?

Para casos simples de captura de mudança de dados (CDC) e reação em tempo quase real, sim — combinado com Lambda, resolve boa parte do que uma ferramenta de ETL faria manualmente. Para pipelines analíticos complexos, com transformação pesada de dados e destino em um data warehouse, vale complementar com serviços dedicados a isso.

Preciso de um DBA para operar o DynamoDB?

Menos do que para um banco relacional tradicional — a AWS gerencia patch, replicação e escala automaticamente. Mas a modelagem de dados, o dimensionamento de capacidade e o monitoramento de custo continuam exigindo conhecimento especializado, especialmente nos primeiros meses de uma migração. Empresas sem essa expertise interna costumam se apoiar em administração de banco de dados terceirizada justamente nesse período.

O DynamoDB Resolve Escala — a Modelagem é Que Decide se Ele Resolve o Seu Problema

O Amazon DynamoDB entrega o que promete: latência de milissegundos em qualquer escala, sem servidor para gerenciar e sem teto prático de crescimento. Mas essa entrega depende inteiramente de uma etapa que o modelo relacional deixa para depois — desenhar os padrões de acesso antes de desenhar a tabela. Empresas que fazem esse trabalho de modelagem com cuidado colhem exatamente a escala e a previsibilidade que buscavam. As que migram tratando o DynamoDB como "um banco mais rápido" descobrem, meses depois, que reescreveram a camada de dados para um modelo que não usa direito.

A pergunta certa nunca é "DynamoDB ou relacional" como escolha definitiva de empresa. É, para cada sistema específico, "os meus padrões de acesso são conhecidos e estáveis o suficiente para valer a troca". Quando a resposta é sim, o ganho é real. Quando não é, o relacional continua sendo a ferramenta certa — e vale revisar essa decisão dentro do AWS Well-Architected Framework, no pilar de excelência operacional, junto com o resto das escolhas de arquitetura da aplicação.

Artigos Relacionados

• RDS Extended Support: o Guia Completo do Ciclo de Vida de Versões do Amazon RDS — para quem decide ficar no modelo relacional, este guia mostra como planejar o ciclo de vida de versões do RDS sem ser pego de surpresa pela cobrança automática do Extended Support.
• Arquitetura Serverless na AWS: Lambda, Step Functions e API Gateway — o DynamoDB é a peça de dados que mais naturalmente se encaixa numa arquitetura serverless; aqui está o resto do desenho.
• FinOps AWS: o Guia Completo para Reduzir Custos na Nuvem — escolher entre on-demand e provisioned no DynamoDB é uma decisão de FinOps tanto quanto de arquitetura; este guia aprofunda a prática.
• Administração de Banco de Dados Terceirizada: o Guia Definitivo — para empresas sem expertise interna em modelagem NoSQL, apoio especializado reduz o risco dos primeiros meses de uma migração.

</content>