2026-09-30
每日一文 · 长文精读
AWS Introduces Foreign Key Constraints in Aurora DSQL
AWS在Aurora DSQL中引入外键约束
作者：Renato Losio · InfoQ 原文
摘要：AWS近日宣布Aurora DSQL支持外键约束，通过快照验证与提交时冲突检测实现引用完整性，无需锁表。此前缺少外键被视为采用该数据库的主要障碍，社区对此功能反响积极，但也有用户担心性能开销。AWS建议保持被引用键稳定以减少冲突，并提醒客户在添加外键前进行基准测试。该功能是DSQL近期多项更新之一。
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.
AWS最近宣布，Aurora DSQL现在支持外键约束，允许应用程序直接在数据库中执行引用完整性，包括CASCADE、SET NULL等引用动作。
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.
Aurora DSQL是一种无服务器、分布式、与PostgreSQL兼容的SQL数据库，专为高可用、可扩展的应用程序而设计。
According to the documentation, Aurora DSQL enforces referential integrity through snapshot verification during transactions and conflict detection at commit time.
根据文档，Aurora DSQL通过在事务期间进行快照验证并在提交时进行冲突检测来强制引用完整性。
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.
该服务在不锁定表的情况下，对照一致的事务快照检查外键关系，从而允许并发操作，并在提交时使用隐式KEY SHARE检查来检测冲突更改；违反约束的事务将被拒绝并返回序列化错误。
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.
对于被大量引用的行，AWS建议避免频繁更改键列；相反，应保持被引用的键稳定，并将变化的值移到非键列以减少事务冲突。
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:
AWS副总裁兼杰出工程师Marc Brooker强调，Aurora DSQL使用Adjudicator和PostgreSQL的KEY SHARE机制，在提交时检测相关行的更改，而不阻塞并发读取：
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:
在LinkedIn上，荷兰铁路公司（Nederlandse Spoorwegen）首席工程师、AWS News Feed创建者Luc van Donkersgoed评论道：
They did it!
他们做到了！
Aurora DSQL now supports foreign key constraints.
Aurora DSQL现在支持外键约束。
Lack of FKs was the biggest gap between DSQL and ‘normal’ Postgres, blocking many migrations.
缺少外键是DSQL与“普通”Postgres之间最大的差距，阻碍了许多迁移。
This change makes DSQL much more viable for brownfield environments.
这一变化使DSQL在现有环境（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.
在“Amazon wasted their time building DSQL”的帖子中，缺少外键约束被认为是采用这种与PostgreSQL兼容的分布式数据库的主要障碍之一。
Marc Bowes, senior principal engineer at AWS, acknowledged at the time:
AWS资深首席工程师Marc Bowes当时承认：
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.
当该服务在2024年re:Invent大会上发布时，许多从业者指出，在启动时缺失的众多功能中，外键约束是其中之一。
User SteveTabernacle2 wrote:
用户SteveTabernacle2写道：
Then "Postgres-compatible" is misleading.
那么“与Postgres兼容”这种说法具有误导性。
Foreign keys is such a big part of RDBMS.
外键是关系数据库管理系统（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:
社区对这一新功能的反应总体上是积极的，但一位用户在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.
考虑到DSQL的架构，我不确定这会带来多大好处。
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.
AWS指出，对被引用表或引用表的所有DML操作都会产生额外的读取以维护引用完整性，客户在向表添加外键约束前应对工作负载进行基准测试。
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.
外键约束并不是最近添加到DSQL的唯一新功能，AWS还增加了CloudWatch Database Insights，用于按语句、集群级别的性能监控和故障排除。
阅读理解
1. How does Aurora DSQL enforce foreign key constraints without locking tables?
2. What was a major criticism of Aurora DSQL when it was first announced?
3. According to AWS, what should applications do to handle transaction failures caused by concurrent conflicts?