O DynamoDB suporta chaves estrangeiras?

Não. O DynamoDB não tem chaves estrangeiras, restrições de integridade referencial nem exclusões em cascata — como banco de dados NoSQL, ele nunca impõe relacionamentos entre itens ou tabelas. Em vez disso, você mesmo modela os relacionamentos: desnormalize os dados relacionados em um único item, ou coloque itens relacionados sob uma chave de partição compartilhada com single-table design. Para ver e percorrer esses relacionamentos modelados, as Smart Tables do DynoTable desenham um relacionamento entre duas tabelas em um canvas e navegam pelas linhas unidas.

Por que não há chaves estrangeiras

Uma chave estrangeira existe para dar suporte a joins e impor integridade entre tabelas normalizadas. O DynamoDB omite deliberadamente o operador JOIN (a AWS recomenda desnormalizar no lugar), então uma restrição de chave estrangeira policiaria um relacionamento que o modelo de consulta nunca explora. Nada impede você de armazenar a chave de outro item como atributo — o DynamoDB simplesmente não vai validá-la nem propagá-la em cascata.

Como os relacionamentos são modelados em vez disso

Embutir — dados filhos pequenos e limitados vivem dentro do item pai como uma lista ou um mapa.
Colocar juntos — pai e filhos compartilham uma chave de partição com chaves de ordenação distintas, então um único Query retorna o relacionamento inteiro; esse é o coração do single-table design.
Duplicar — copie os campos de que cada padrão de acesso precisa para os itens que precisam deles, aceitando a manutenção no momento da escrita em troca de leituras de uma única requisição.

Os guias de um-para-muitos e muitos-para-muitos cobrem cada formato em profundidade.

Impondo integridade quando isso importa

Para os casos em que você teria se apoiado em uma restrição, o DynamoDB te dá blocos de construção: expressões de condição protegem uma escrita com base no estado do item que está sendo escrito, e o ConditionCheck de uma transação pode verificar se um item diferente (digamos, o pai) existe na mesma operação tudo-ou-nada. Exclusões em cascata viram lógica explícita da aplicação ou uma limpeza orientada por Streams.

Como isso fica quando você executa

Colocamos um item PROFILE e dois itens ORDER# sob pk = "CUSTOMER#1", excluímos o perfil e consultamos a partição novamente:

Count: 2
[{"sk":{"S":"ORDER#1"},"pk":{"S":"CUSTOMER#1"}},
 {"sk":{"S":"ORDER#2"},"pk":{"S":"CUSTOMER#1"}}]

A exclusão retornou sucesso. Dois órfãos, sem aviso, sem erro para capturar. No PostgreSQL a mesma exclusão falha, propaga em cascata ou anula a referência do filho, dependendo de qual restrição você declarou.

Depois, o substituto mais próximo: um TransactWriteItems que faz a checagem de condição no pai antes de escrever um terceiro pedido.

TransactionCanceledException: Transaction cancelled, please refer cancellation
reasons for specific reasons [ConditionalCheckFailed, None]

CancellationReasons: [
  {"Code":"ConditionalCheckFailed","Message":"The conditional request failed."},
  {"Code":"None"}
]

As posições do array correspondem às posições dos seus TransactItems, então [ConditionalCheckFailed, None] diz que a ação 0 (a checagem do pai) falhou e a ação 1 (a escrita do filho) estava bem. Com uma única proteção isso se lê facilmente; com oito ações, esse array é a única forma de descobrir qual delas quebrou.

E é cobrado também. Uma escrita transacional consome duas unidades de escrita por item, e a AWS é explícita ao dizer que "this capacity is consumed even when the transaction is canceled". Cada escrita rejeitada custa o mesmo que uma aceita.

Aprofunde-se

Comece com single-table design, construa as condições de proteção no expression builder, e baixe o DynoTable para navegar por esses relacionamentos visualmente — suas Smart Tables unem tabelas pai e filho em um canvas para que você veja a coleção de itens inteira em uma única visão.

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.

A consulta dos filhos órfãos e a saída de cancelamento foram reproduzidas em 2026-07-28 contra o DynamoDB Local 3.3.0 com @aws-sdk/client-dynamodb 3.1095.0 no Node v24.18.0.