Aurora DSQL ya deja declarar FOREIGN KEY en tablas nuevas y existentes. AWS lo anunció el 27 de agosto y con eso cierra uno de los huecos que más fricción generaba al mover un esquema relacional de PostgreSQL a su base distribuida activo-activo: hasta ahora, la integridad referencial era problema de tu aplicación.
Qué pasó
El anuncio es corto y no tiene asteriscos: puedes declarar constraints de llave foránea en clusters de Aurora DSQL, tanto al crear la tabla como agregándolas a tablas que ya están en producción. El motor rechaza cualquier escritura que dejaría una fila apuntando a un registro que ya no existe.
Vienen las cinco acciones referenciales completas de PostgreSQL para el borrado o la actualización de la fila referenciada: NO ACTION, RESTRICT, CASCADE, SET NULL y SET DEFAULT. Está disponible en todas las regiones donde ya opera Aurora DSQL y sin costo extra.
Por qué importa
Suena a checkbox de documentación, y es exactamente lo contrario. En una base distribuida, una llave foránea no es una línea en el DDL: es una verificación remota dentro del camino crítico de cada escritura. Cada INSERT en la tabla hija obliga a comprobar que el padre existe, y cada DELETE en el padre obliga a saber si alguien lo referencia. En una sola instancia de PostgreSQL eso es un lookup local. En un sistema que reparte storage y coordinación entre nodos y regiones, es coordinación adicional, con su costo en latencia y en conflictos.
Por eso las bases distribuidas históricamente empujaron el problema a la capa de aplicación: "valida tú". Y por eso el patrón real que se ve en producción es un ejército de validaciones a mano, triggers caseros y trabajos nocturnos que buscan filas huérfanas después del hecho. Todo eso se puede borrar.
Para quien evalúa migraciones el cambio es de categoría. Un esquema legado de PostgreSQL con decenas de FKs ya no requiere reescribir la lógica de integridad para entrar a DSQL: entra tal cual. Y para quien ya está adentro, la constraint pasa de ser deuda documentada a garantía del motor.
El detalle técnico
Para entender por qué esto tardó, hay que ver cómo está construido DSQL. El paper que publicó su propio equipo en julio (Brooker, Bowes, Hershey, van der Merwe, Morle y Strydom) describe una arquitectura desagregada: cómputo, storage y coordinación transaccional son servicios independientes que escalan por separado. Los query processors corren en MicroVMs de Firecracker ejecutando SQL compatible con PostgreSQL sin estado local.
La pieza clave está en cómo maneja las transacciones:
El sistema usa control de concurrencia multiversión con timestamps de precisión para lecturas sin coordinación, y control de concurrencia optimista para escrituras, diferiendo la coordinación al momento del commit a través de adjudicadores distribuidos y el sistema de replicación Journal. — Brooker et al., Aurora DSQL: Scalable, Multi-Region OLTP
Ahí está la clave del diseño y también la de esta feature. DSQL no coordina por cada statement, sino una sola vez al hacer commit. Eso es lo que le permite operar activo-activo en varias regiones sin pagar un round-trip transregional por cada instrucción. Una llave foránea, en cambio, es una lectura que debe ser consistente con el estado final de la transacción, no con el que se leyó al inicio. Implementarla sin romper el modelo optimista significa arrastrar esa verificación al conjunto que se valida en el commit, no resolverla antes.
En la práctica esto tiene dos consecuencias que conviene tener en mente antes de rociar FKs por todo el esquema:
- Los conflictos se manifiestan en el commit, no en el
INSERT. Con OCC, la transacción puede fallar al final. Tu código necesita lógica de retry: no es opcional, es el contrato del motor. - Un padre muy referenciado es un punto caliente. Tablas de catálogo pequeñas contra las que todo mundo valida concentran contención. Es el mismo razonamiento que aplicas al elegir una partition key.
Y CASCADE merece un párrafo aparte. Borrar una fila que arrastra miles de hijas en un sistema distribuido no es la operación barata que parece en una sola instancia: amplifica el trabajo de la transacción y su probabilidad de conflicto. En DSQL, CASCADE es una función a usar con criterio, no por defecto.
Qué hacer
- Si tenías validación de integridad en la aplicación, la puedes migrar al motor — pero antes audita si ya hay filas huérfanas: agregar la constraint a una tabla existente valida los datos que ya están ahí.
- Revisa que tu cliente maneje reintentos de commit. Con OCC no es defensivo, es el diseño.
- Defaultea a
NO ACTIONoRESTRICT. DejaCASCADEpara relaciones de cardinalidad acotada y documentada. - Si tenías una evaluación de DSQL congelada por este hueco, es momento de reabrirla. La feature llega junto a otras señales de maduración del servicio en agosto: observabilidad en CloudWatch, métricas por statement en Database Insights y streaming de cambios hacia Apache Iceberg.
La lectura de fondo: DSQL dejó de venderse como "base distribuida a la que le adaptas el esquema" y empezó a pelear en el terreno donde compiten en serio, que es el de correr esquemas relacionales de verdad, con sus reglas intactas.
Fuentes
- Amazon Aurora DSQL now supports foreign key constraints — AWS What's New
- Aurora DSQL: Scalable, Multi-Region OLTP — arXiv:2607.13276
- Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch — AWS Database Blog
- Unlocking real-time analytics: Streaming Aurora DSQL changes into Apache Iceberg — AWS Database Blog