Aurora DSQL gets foreign keys after nearly two years without support

AWS announced that Aurora DSQL, its serverless, distributed database compatible with PostgreSQL, now supports foreign key constraints, including referential actions like CASCADE and SET NULL. The news was reported by InfoQ on September 28, 2026, and closes a gap that the technical community itself had been demanding since the service launched at re:Invent 2024.

The absence of foreign keys was, until now, the most frequently cited reason for not migrating legacy Postgres systems to DSQL. Without this feature, applications that relied on database-level referential integrity had to reimplement that logic in the application layer, which in practice made most migrations of existing databases (brownfield) unfeasible.

How verification works without locking tables

The most relevant technical point for those designing distributed schemas is how Aurora DSQL implements referential integrity. According to AWS documentation cited by InfoQ, the service does not use traditional table locks. Instead, it performs snapshot verification during the transaction and conflict detection at commit time.

In practice, this means:

• Foreign key relationships are checked against a consistent snapshot of the transaction, without blocking concurrent reads or writes.
• At commit time, the database uses implicit KEY SHARE checks (a mechanism native to Postgres) to detect conflicting changes in referenced rows.
• Transactions that would violate a constraint are rejected with a serialization error, rather than waiting in a queue.

Marc Brooker, VP and Distinguished Engineer at AWS, described the mechanism behind this, named Adjudicator, summarizing the expected behavior: no locking, no change in scale for reads that don't involve foreign keys, readers checking FKC never cause other readers to abort, and good scalability for well-distributed workloads (source).

What changes in application design

For those building on DSQL, the direct consequence is architectural: since conflicts result in transaction failure rather than waiting, the application needs to implement retry logic. This differs from the mental model most developers carry over from traditional Postgres, where pessimistic locks hold the concurrent transaction until the resource is released.

AWS also recommends a specific modeling precaution: for heavily referenced rows (a users table referenced by dozens of others, for example), it's better to avoid key columns that change frequently. The guidance is to keep referenced keys stable and move frequently changing values to columns that aren't part of the key, thereby reducing transaction conflicts.

This is a real cost trade-off: AWS states that every DML operation on tables that are referenced or that reference others now performs additional reads to maintain referential integrity, and explicitly recommends that teams benchmark their workload before adding a foreign key constraint to a production table.

The community pressure that drove the change

The history of this demand is well documented. When Aurora DSQL was announced at re:Invent 2024, the lack of foreign keys was already pointed out as one of its main limitations. A user identified as SteveTabernacle2 went as far as questioning the product's own positioning at the time: "Postgres-compatible" is misleading. Foreign keys are such a big part of RDBMS. You can't have truly "relational" data without foreign keys.

AWS's response came from Marc Bowes, senior principal engineer at the company, in a thread known as "Amazon wasted their time building DSQL": "And yes, foreign keys are coming. We heard you."

Now that the feature has arrived, the reaction from those dealing with legacy system migrations was swift. Luc van Donkersgoed, principal engineer at Nederlandse Spoorwegen (the Dutch national railway operator) and creator of the AWS News Feed, commented on LinkedIn: "They did it! Aurora DSQL now supports foreign key constraints. The lack of FKs was the biggest gap between DSQL and 'regular' Postgres, blocking many migrations. This change makes DSQL much more viable for brownfield environments."

The skepticism that remains

Not every reaction was pure celebration. In a Reddit thread cited by InfoQ, a user raised the concern that matters most to anyone putting this into production: "I know this feature was pointed out as one of the main adoption blockers, but this makes things quite a bit slower. I'm not sure how good this is going to be given DSQL's architecture."

The concern makes sense given AWS's own warning about additional reads on every DML operation. Unlike a Postgres instance running on a single node, DSQL is distributed by design, and any referential integrity verification mechanism carries a coordination cost across nodes. The recommendation to benchmark before applying the constraint isn't just generic caution, it's an explicit acknowledgment that the performance impact varies by workload.

Additional context: CloudWatch Database Insights

The arrival of foreign keys wasn't the only recent development in DSQL. AWS also added support for CloudWatch Database Insights, with per-statement and cluster-level monitoring, enabling more granular performance troubleshooting. For teams planning to test foreign key constraints under real workloads, this tool is the natural path to measuring the impact of the additional reads mentioned by AWS itself, before deciding whether it's worth applying the constraint to high-traffic tables.

What remains open for those evaluating DSQL

For Brazilian teams that currently maintain traditional Postgres databases and are considering migrating to a serverless database with automatic scaling, the feature removes a real entry barrier, but it doesn't eliminate the need to rethink data access patterns. Anyone migrating needs to validate two concrete points before deciding: whether the application already handles serialization errors with retry logic (or needs to be adapted to do so), and whether the schema has key columns that change frequently and would need to be remodeled to reduce conflicts. Neither of these two points is trivial to resolve once the system is already in production.