AWS recently announced that Aurora DSQL now supports foreign key constraints, allowing applications to enforce referential integrity directly in the database, including CASCADE, SET NULL, and other referential actions. The addition addresses a long-standing gap that users had explicitly called out as an adoption blocker.
Aurora DSQL is a serverless, distributed, PostgreSQL-compatible SQL database designed for highly available, scalable applications. According to the documentation, Aurora DSQL enforces referential integrity through snapshot verification during transactions and conflict detection at commit time. The service checks foreign key relationships against a consistent transaction snapshot without locking tables, allowing concurrent operations, and uses implicit KEY SHARE checks at commit to detect conflicting changes; transactions that would violate a constraint are rejected with a serialization error.
Applications should implement retry logic because concurrent conflicts result in transaction failures rather than waits. For heavily referenced rows, AWS suggests avoiding frequently changing key columns; instead, keep referenced keys stable and move changing values to non-key columns to reduce transaction conflicts.
Marc Brooker, VP and Distinguished Engineer at AWS, highlights that Aurora DSQL uses the Adjudicator and PostgreSQL's KEY SHARE mechanism to detect changes to relevant rows at commit time without blocking concurrent reads:
No blocking, no change in scaling for non-FKC reads, FKC readers never cause other readers to abort, and great FKC scaling for well-distributed workloads.
On LinkedIn, Luc van Donkersgoed, principal engineer at Nederlandse Spoorwegen and creator of AWS News Feed, comments:
They did it! Aurora DSQL now supports foreign key constraints. Lack of FKs was the biggest gap between DSQL and ‘normal’ Postgres, blocking many migrations. This change makes DSQL much more viable for brownfield environments.
In the "Amazon wasted their time building DSQL" thread, the lack of foreign key constraints was mentioned as one of the main blockers for the adoption of the PostgreSQL-compatible distributed database. Marc Bowes, senior principal engineer at AWS, acknowledged at the time:
And yes, foreign keys are coming. We heard ya.
When the service was announced at re:Invent 2024, many practitioners highlighted the lack of foreign key constraints among the many missing features at launch. User SteveTabernacle2 wrote:
Then "Postgres-compatible" is misleading. Foreign keys is such a big part of RDBMS. You can't truly have "relational" data without foreign keys.
The reaction of the community to the new feature has been largely positive, but a user questions on Reddit:
I know this feature was quoted as one of the main adoption blockers, but it slows things down a lot. I'm not sure how good this is going to be considering DSQL's architecture.
AWS notes that all DML operations on referenced or referencing tables incur additional reads to maintain referential integrity and that customers should benchmark the workload before adding a foreign key constraint to a table.
Foreign key constraints were not the only new capability recently added to DSQL, with AWS also adding CloudWatch Database Insights for per-statement, cluster-level performance monitoring and troubleshooting.