¿DynamoDB admite claves foráneas?

No. DynamoDB no tiene claves foráneas, ni restricciones de integridad referencial, ni borrados en cascada — como base de datos NoSQL, nunca impone relaciones entre Items o tablas. En su lugar, modelas tú las relaciones: desnormaliza los datos relacionados dentro de un Item, o coloca los Items relacionados juntos bajo una clave de partición compartida con el diseño de tabla única. Para ver y recorrer esas relaciones modeladas, las Smart Tables de DynoTable dibujan una relación entre dos tablas sobre un lienzo y exploran las filas unidas.

Por qué no hay claves foráneas

Una clave foránea existe para dar soporte a los joins e imponer la integridad entre tablas normalizadas. DynamoDB omite deliberadamente el operador JOIN (AWS recomienda desnormalizar en su lugar), así que una restricción de clave foránea vigilaría una relación que el modelo de consulta nunca aprovecha. Nada te impide guardar la clave de otro Item como atributo — DynamoDB simplemente no la validará ni la propagará.

Cómo se modelan las relaciones en su lugar

Incrustar — los datos hijos pequeños y acotados viven dentro del Item padre como lista o mapa.
Colocar juntos — padre e hijos comparten una clave de partición con claves de ordenación distintas, de modo que un solo Query devuelve la relación entera; este es el corazón del diseño de tabla única.
Duplicar — copia los campos que necesita cada patrón de acceso en los Items que los necesitan, aceptando mantenimiento en la escritura a cambio de lecturas de una sola petición.

Las guías de uno a muchos y muchos a muchos cubren cada forma en profundidad.

Imponer la integridad cuando importa

Para los casos en los que te habrías apoyado en una restricción, DynamoDB te da piezas de construcción: las expresiones de condición protegen una escritura según el estado del Item que se está escribiendo, y el ConditionCheck de una transacción puede verificar que existe un Item distinto (por ejemplo, el padre) dentro de la misma operación de todo o nada. Los borrados en cascada se convierten en lógica explícita de la aplicación o en una limpieza dirigida por Streams.

Qué aspecto tiene cuando lo ejecutas

Pusimos un Item PROFILE y dos Items ORDER# bajo pk = "CUSTOMER#1", borramos el perfil y volvimos a consultar la partición:

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

El borrado devolvió éxito. Dos huérfanos, sin aviso, sin error que capturar. En PostgreSQL el mismo borrado falla, cae en cascada o pone a null la referencia del hijo, según qué restricción declararas.

Luego, el reemplazo más cercano: un TransactWriteItems que comprueba la condición del padre antes de escribir un tercer pedido.

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

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

Las posiciones del array coinciden con las posiciones de tus TransactItems, así que [ConditionalCheckFailed, None] dice que la acción 0 (la comprobación del padre) falló y que la acción 1 (la escritura del hijo) estaba bien. Con una sola guarda eso se lee sin problema; con ocho acciones, ese array es la única manera de averiguar cuál se rompió.

Y factura, además. Una escritura transaccional consume dos unidades de escritura por Item, y AWS es explícito en que "this capacity is consumed even when the transaction is canceled". Cada escritura rechazada cuesta lo mismo que una aceptada.

Profundiza

Empieza por el diseño de tabla única, construye las condiciones de guarda en el generador de expresiones y descarga DynoTable para explorar esas relaciones visualmente — sus Smart Tables unen las tablas padre e hija sobre un lienzo para que veas la colección de Items completa en una sola vista.

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.

La consulta de los hijos huérfanos y la salida de cancelación se reprodujeron el 2026-07-28 contra DynamoDB Local 3.3.0 con @aws-sdk/client-dynamodb 3.1095.0 en Node v24.18.0.