O modelo de custo do DynamoDB: por que o SQL pode esconder a conta

Rodar SQL de verdade sobre o DynamoDB é poderoso — você ganha JOINs, GROUP BY e cláusulas WHERE arbitrárias sobre um banco de dados que nativamente não oferece nenhum deles. Mas o SQL foi projetado para um mecanismo com um planejador de consultas e índices secundários em cada coluna, e o DynamoDB não tem nenhum dos dois. Um SELECT perfeitamente válido pode compilar para um Scan de tabela inteira que lê — e cobra de você por — cada item da tabela.

Essa é a faca de dois gumes da abstração do SQL: ela faz padrões de acesso caros parecerem gratuitos. Este guia explica o modelo de custo por baixo, para que a conveniência nunca vire uma conta surpresa, e mostra como o DynoTable expõe o custo antes de você executar a consulta.

Por que o SQL sobre o DynamoDB custa mais do que parece?

Um banco de dados relacional consegue responder WHERE status = 'active' de forma eficiente porque cria um índice para qualquer coluna que você pedir. O DynamoDB não. Ele responde de forma eficiente a exatamente uma coisa: a chave de partição (opcionalmente restringida por uma chave de classificação ou um índice secundário global). Qualquer outra coisa é um Scan.

• Uma igualdade na chave de partição é um Query. O DynamoDB salta direto para os itens sob aquela chave e lê apenas esses. Limitado e barato.
• Qualquer outra coisa é um Scan + Filter. O DynamoDB lê cada item da tabela e então aplica o seu WHERE como uma FilterExpression — depois da leitura. Você é cobrado por tudo que ele escaneou, não pela meia dúzia de linhas retornadas.

Esse último ponto é a armadilha. Uma cláusula WHERE parece restringir o trabalho. Em um atributo que não é chave, ela só restringe a saída — o custo de leitura já foi gasto.

Query vs Scan: a matemática de RCU

O DynamoDB cobra leituras em unidades de capacidade de leitura (RCU):

• 1 RCU = uma leitura fortemente consistente de um item de até 4 KB. Leituras eventualmente consistentes custam metade de uma unidade. As leituras são arredondadas para cima a cada 4 KB.
• Um Query lê apenas os itens sob uma chave de partição — o custo escala com os itens correspondentes, não com a tabela.
• Um Scan lê a tabela inteira, 4 KB por vez. Uma tabela de 1 GB é aproximadamente 262.000 RCU eventualmente consistentes para uma única passagem completa — a cada passagem, toda vez.

Uma FilterExpression não reduz esse número. A filtragem acontece depois da leitura, então um Scan filtrado custa exatamente o mesmo que um sem filtro. Calcule os números reais dos seus dados com a calculadora de tamanho de item e a calculadora de preços.

Quais construções SQL viram Scans silenciosamente?

• WHERE sem igualdade na chave de partição → um Scan completo com um filtro pós-leitura.
• JOIN → não existe join no lado do servidor no DynamoDB. Cada tabela unida é buscada separadamente e costurada no lado do cliente — um padrão de acesso N+1, uma requisição por linha unida.
• COUNT, SUM, GROUP BY, agregações → não existe agregação no lado do servidor, então cada item correspondente é lido. Sobre um Scan, isso significa ler a tabela inteira.
• ORDER BY ou DISTINCT em um atributo que não é chave → a ordenação e a remoção de duplicatas acontecem no lado do cliente sobre o que quer que tenha sido escaneado.

Nenhuma dessas é errada de rodar — às vezes um Scan é exatamente o que você quer. O ponto é saber quando você está rodando um.

Como manter o SQL honesto quanto ao custo?

• Projete as chaves em torno dos seus padrões de acesso. A consulta mais barata é aquela que o seu esquema de chaves já responde. Planeje-a com a ferramenta de single-table design e o guia de Query vs Scan.
• Coloque uma igualdade na chave de partição no WHERE para obter um Query em vez de um Scan.
• Adicione um GSI para um segundo padrão de acesso em vez de escanear e filtrar.
• Leia o custo antes de rodar. O Workbench do DynoTable compila o seu SQL para a operação real do DynamoDB e mostra o plano — Scan vs Query, qual índice ele usa, a condição de chave vs o filtro pós-Scan, e um custo estimado em RCU — e então sinaliza scans completos e joins N+1 inline. É o EXPLAIN que o DynamoDB nunca lançou. Veja também por que os scans são lentos e caros e capacidade On-Demand vs Provisionada.

O SQL do DynoTable piora o problema de custo?

Não — porque ele torna o custo visível. A crítica ao SQL sobre o DynamoDB é justa: uma abstração que esconde scans deixa você dar um tiro no próprio pé. A resposta do DynoTable não é remover o SQL, mas colocar um raio-X de custo por trás dele. Toda consulta no Workbench mostra a prévia da sua forma real no DynamoDB antes de rodar, então você mantém a ergonomia do SQL e a honestidade sobre RCUs e design de chaves que o modelo nativo oferece.

Preciso do agente de IA para algo disso?

Não — o visualizador de tabelas, o SQL Workbench e a prévia de custo funcionam todos plenamente sem ele. O agente de IA é um dos recursos de destaque do DynoTable — um agente de código nativo do DynamoDB que escreve consultas cientes do schema, transforma dados e muito mais — e ele está lá sempre que você quiser. Ele roda no seu próprio AWS Bedrock, então você paga a AWS diretamente a preço de custo (sem markup), e seus dados nunca saem da sua conta. Ative-o quando ajudar; o cliente principal está completo de qualquer forma.

Meu trabalho é portável?

Sim. O DynoTable fala padrões, não um jardim murado: SQL padrão, credenciais e SSO padrão da AWS, exportação CSV/JSON, exportação de schema inferido para TypeScript, JSON-Schema ou Zod, e um servidor MCP para que suas próprias ferramentas e agentes possam se conectar. Suas consultas, configurações e schemas exportam de forma limpa — nada fica preso.

Experimente

Baixe o DynoTable e abra o SQL Workbench sobre a sua própria tabela — a prévia de custo mostra a você o que cada consulta realmente custa antes de você rodar.