O DynamoDB carrega uma fama dupla: para uns, é o banco mágico que aguenta a Amazon no pico da Black Friday sem um DBA de plantão; para outros, é a armadilha onde queries simples viram impossíveis. As duas famas são verdadeiras, e a diferença entre elas é uma só: entender o contrato antes de assinar.

O contrato: você troca flexibilidade por garantias

DynamoDB é o banco NoSQL serverless da AWS (aws.amazon.com/dynamodb): totalmente gerenciado, com latência de milissegundos de um dígito em qualquer escala: mil ou mil milhões de itens, o tempo de resposta é o mesmo. Sem servidor para dimensionar, sem manutenção, escala automática, pagamento por requisição.

O preço dessa mágica é o modelo de acesso: você só consulta eficientemente pelo que planejou de antemão. Cada item tem uma partition key (que determina onde o dado mora) e opcionalmente uma sort key (que ordena dentro da partição). Consultas rápidas são: "me dê o item com esta chave" ou "me dê os itens desta partição, neste intervalo de sort key". E só.

// Rápido em qualquer escala: busca por chave
await ddb.query({
  TableName: "Pedidos",
  KeyConditionExpression: "clienteId = :c AND dataPedido > :d",
  ExpressionAttributeValues: { ":c": "CLI-042", ":d": "2026-01-01" },
});

// A armadilha: Scan varre a TABELA INTEIRA (lento e caro em escala)
await ddb.scan({ TableName: "Pedidos", FilterExpression: "total > :t", ... });

Scan com filtro parece uma query; na verdade lê tudo e joga fora o que não serve, cobrando pela leitura de tudo. É o KEYS * do mundo DynamoDB: funciona na demo, explode na fatura.

Modelar de trás para frente

No relacional, você modela as entidades e depois escreve qualquer query. No DynamoDB, inverte: lista primeiro os padrões de acesso ("buscar pedidos do cliente por período", "buscar pedido por id", "listar itens do pedido"), e desenha as chaves para servi-los.

• Access patterns → chaves. Cada pergunta frequente precisa de uma resposta por chave (ou por índice secundário, os GSIs, que são, na prática, cópias da tabela com outras chaves, pagas à parte).
• Single-table design: o padrão avançado da comunidade coloca várias entidades na mesma tabela com chaves compostas (CLI-042 / PEDIDO#2026-07-13#...), permitindo buscar o cliente e seus pedidos numa única query. Poderoso, e com curva de aprendizado real.
• A pergunta nova exige migração. "Agora quero listar pedidos por vendedor" sem índice previsto = criar GSI e reprocessar. A rigidez é o custo da latência constante.

Quando o DynamoDB é a escolha certa

1. Arquiteturas serverless: com Lambda (tema da série de AWS deste blog), o par é natural: sem conexão persistente, sem pool, escala junto.
2. Carga massiva com acesso por chave: carrinho, sessão, perfil, catálogo por ID, IoT, gaming: padrões previsíveis em escala brutal.
3. Operação mínima como requisito: sem time de banco, sem janela de manutenção, sem servidor para caçar às 3h.
4. Picos extremos: o modo on-demand absorve 100x de tráfego sem provisionar nada antes.

Quando fugir dele

• Consultas ad hoc e relatórios: "quanto vendemos por região no trimestre?" não é pergunta para DynamoDB. O padrão maduro: Dynamo na operação, exportando via eventos para um banco analítico.
• Modelo em evolução rápida: produto em Discovery, perguntas mudando toda semana: a rigidez cobra caro. PostgreSQL flexível até o padrão estabilizar.
• Transações relacionais complexas: existem transações no Dynamo, mas se o seu domínio é uma teia de integridade referencial, você está no banco errado.

A fatura, sem surpresa

Paga-se por unidades de leitura/escrita (RCU/WCU) e armazenamento. As pegadinhas: item grande custa múltiplas unidades por operação; GSI dobra o custo de escrita de cada item indexado; Scan cobra pela tabela inteira. A boa notícia: o custo é proporcional ao uso e previsível por design, sem instância ociosa, FinOps embutido para quem modelou direito.

O resumo de bolso

DynamoDB é excepcional quando as perguntas são conhecidas e a escala é o problema. É frustrante quando as perguntas mudam toda semana. Definir em qual caso você está (e desenhar a tabela de trás para frente, a partir dos access patterns) é o tipo de modelagem que fazemos no serviço de Arquitetura de Software.

Liste suas 5 consultas mais frequentes e conte para a IA da Rabelo Digital, aqui no canto da tela: ela diz se cabem em chaves do Dynamo ou se o seu caso pede outro banco. Sem formulário, sem espera.

---

Leia também

• Modelagem de dados: a decisão que sobrevive aos frameworks
• PostgreSQL vs MongoDB: como escolher
• Redis: muito além do cache