O DynamoDB é um banco de dados relacional?

Não. O DynamoDB não é um banco de dados relacional — ele é um armazenamento NoSQL de chave-valor e documentos. Não há tabelas com schemas fixos, não há chaves estrangeiras e não há joins. Você modela os dados em torno dos padrões de acesso da sua aplicação e desnormaliza, em vez de normalizar entre tabelas relacionadas como faria em um banco relacional (SQL). Se você sente falta do fluxo de trabalho relacional, o DynoTable traz parte dele de volta no cliente: um SQL Workbench que roda JOIN e GROUP BY de verdade, e Smart Tables que unem tabelas visualmente.

Por que ele não é relacional

Bancos de dados relacionais impõem um schema, normalizam os dados em muitas tabelas e as unem no momento da leitura. O DynamoDB faz o oposto: ele armazena itens sem schema e espera que você pré-una os dados duplicando ou embutindo o que é relacionado.

O que substitui os recursos relacionais

Joins → desnormalização e single-table design.
Tabelas normalizadas → coleções de itens agrupadas sob uma mesma chave de partição.
SQL ad-hoc → Query e Scan baseados em chave, ou PartiQL (um subconjunto compatível com SQL, ainda sem joins).

O PartiQL não fecha essa lacuna, aliás. O parser dele rejeita um SELECT de duas tabelas e rejeita GROUP BY, ambos antes de ler qualquer coisa; as recusas exatas estão citadas em o DynamoDB suporta joins e o DynamoDB suporta SQL.

O que desnormalizar custa de verdade

A troca costuma ser descrita como "duplicar dados em vez de unir", o que soa como uma decisão de armazenamento. Na verdade é uma decisão de escrita e de atomicidade, e essa é a parte que os motores relacionais escondem de você.

Pegue um cliente com 5.000 pedidos e suponha que ele mude o nome de exibição. Em um schema relacional isso é um UPDATE em uma linha, e todo join passa a enxergar o novo valor imediatamente. Desnormalizado no DynamoDB, o nome vive nos 5.000 itens de pedido, então a renomeação são 5.000 escritas de item: 5.000 unidades de escrita, cerca de US$0,003 em us-east-1 no on-demand, a 1 KB por item.

O dinheiro não é nada. O problema é que isso não pode ser uma operação só. O TransactWriteItems tem teto de 100 ações, então 5.000 itens são pelo menos 50 transações separadas, e não há isolamento entre elas. Enquanto esse fan-out roda, os seus próprios dados discordam de si mesmos, e qualquer leitura que caia no meio do caminho vê uma mistura de nomes antigos e novos.

Os bancos relacionais te compram exatamente isso: uma mudança atômica em uma cópia autoritativa. Abrir mão disso é o preço real de entrada, e é por isso que "quais atributos são duplicados" merece mais atenção de design do que quais são indexados.

Aprofunde-se

Leia como modelar dados no DynamoDB e single-table design. Baixe o DynoTable para explorar o seu modelo de dados visualmente — e rodar consultas JOIN/GROUP BY em estilo relacional sobre ele com o SQL Workbench.

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima; o teto de 100 ações por transação foi reconsultado na referência da API em 2026-07-28.