從 re:Invent 發布到最大的採用障礙
Aurora DSQL 是 AWS 推出的無伺服器、分散式且與 PostgreSQL 相容的 SQL 資料庫，主要面向需要高可用性與水平擴展能力的應用。這項服務在 2024 年的 re:Invent 大會上正式發表，當時的產品定位強調分散式架構下的強一致性與近乎無上限的擴展性，但發表的同時，許多實務工作者很快指出它在功能面上的缺口，其中最常被點名的一項，就是外鍵約束（foreign key constraint）的缺席。
外鍵約束是關聯式資料庫的基本機制，用來確保一張表中參照到另一張表的欄位值確實存在，藉此維持參照完整性（referential integrity）。在 PostgreSQL 等傳統關聯式系統中，這類約束由資料庫引擎直接強制執行，應用程式不必自行檢查每一筆寫入是否對應到有效的父資料列。當一個標榜「PostgreSQL 相容」的資料庫缺少這項能力，對於既有系統的遷移而言就成了明顯的阻礙。當時社群討論中，有開發者直言，若沒有外鍵，所謂的關聯式資料就失去意義，「Postgres 相容」的說法也顯得誇大。AWS 的資深首席工程師 Marc Bowes 後來在討論串中回應，承認外鍵功能正在開發中，也確實聽到了使用者的聲音。
新功能與運作方式
根據 InfoQ 記者 Renato Losio 的報導，AWS 近期宣布 Aurora DSQL 正式支援外鍵約束，應用程式現在可以直接在資料庫層強制參照完整性，並支援 CASCADE、SET NULL 等參照動作。所謂參照動作，指的是當被參照的父資料列遭到刪除或更新時，資料庫該如何處理子資料列：CASCADE 會連帶刪除或更新子資料列，SET NULL 則將子資料列的外鍵欄位設為空值。這些行為過去在 PostgreSQL 中是標準配備，如今才在 DSQL 上補齊。
比較值得注意的是它如何在分散式架構下實作。根據官方文件，Aurora DSQL 不是靠傳統的資料列鎖定來維護參照完整性，而是透過交易期間的快照驗證（snapshot verification），搭配提交時的衝突偵測。系統會在一致的交易快照上檢查外鍵關係，過程中不鎖定資料表，因此並行操作不受阻擋；到了提交階段，則使用隱式的 KEY SHARE 檢查來偵測是否有衝突的變更。若某筆交易會違反約束，該交易會以序列化錯誤（serialization error）被拒絕，而不是排隊等待。
這樣的設計帶來一個實務上的直接後果：應用程式必須自行實作重試邏輯。因為並行衝突會讓交易直接失敗，而不是自動等待前一個交易完成，開發者不能再假設資料庫會替他們排解競爭。此外，AWS 也針對被大量參照的資料列提出建議，呼籲避免使用經常變動的欄位作為鍵，應該讓被參照的鍵維持穩定，把會變動的值移到非鍵欄位，以降低交易衝突的機率。
關鍵在仲裁者與 KEY SHARE，而非鎖定
AWS 副總裁暨傑出工程師 Marc Brooker 對這項實作的說明，點出了技術上的核心。他表示 Aurora DSQL 使用名為 Adjudicator 的仲裁機制，結合 PostgreSQL 的 KEY SHARE 機制，在提交時偵測相關資料列是否發生變更，同時不阻塞並行讀取。KEY SHARE 是 PostgreSQL 中相對寬鬆的鎖定模式，它的作用是防止資料列被刪除或鍵值被改動，但允許其他讀取與部分更新同時進行，因此不像傳統的獨佔鎖那樣讓並行度大幅下降。Adjudicator 則負責在交易提交的關鍵時刻判斷是否存在衝突，扮演裁決角色。
Brooker 進一步列出這套做法的特性：沒有阻塞、非外鍵約束相關的讀取在擴展性上不受影響、進行外鍵檢查的讀取者不會導致其他讀取者中止，而且在資料分布良好的工作負載下，外鍵檢查本身也有不錯的擴展表現。這段描述回應的正是分散式資料庫最難處理的取捨：一旦在跨節點的交易中加入全域性的約束檢查，很容易演變成節點之間的協調瓶頸，甚至因為互相等待而拖垮整體吞吐量。DSQL 選擇以驗證加衝突偵測取代鎖定與等待，把衝突的處理成本轉移到應用層的重試。
社群反應、效能代價與適用情境
這項更新在社群中大致獲得正面評價。Nederlandse Spoorwegen 首席工程師、同時也是 AWS News Feed 創作者的 Luc van Donkersgoed 在 LinkedIn 上表示，缺乏外鍵是 DSQL 與「正常」Postgres 之間最大的差距，阻礙了許多遷移，這次補齊讓 DSQL 對既有系統環境（brownfield）的適用性大幅提升。不過也有開發者在 Reddit 上提出保留，認為雖然外鍵確實是主要的採用障礙，但它會明顯拖慢速度，考慮到 DSQL 的架構特性，實際表現仍有待觀察。
這樣的疑慮並非沒有根據。AWS 自己在文件中說明，對被參照表或參照表所做的所有 DML 操作，都會產生額外的讀取來維護參照完整性，因此建議客戶在替資料表加上外鍵約束之前，先針對自己的工作負載進行基準測試。換言之，外鍵不是免費的，它的成本會隨著作為參照目標的資料列熱度與存取模式而變化；對於鍵值頻繁變動，或大量交易同時指向同一批熱門資料列的場景，衝突與重試的機率都會上升。
除了外鍵約束，AWS 近期也為 DSQL 加入 CloudWatch Database Insights，提供逐語句與叢集層級的效能監控與疑難排解能力。對於一個以分散式交易為核心、又剛開始要求應用層承擔重試責任的資料庫而言，這類可觀測性工具的重要性不亞於功能本身，因為開發團隊必須能看清序列化錯誤從何而來、哪些語句產生了額外的驗證讀取，才有辦法調整資料模型與存取策略。整體來看，外鍵支援讓 Aurora DSQL 更接近它所宣稱的 PostgreSQL 相容定位，但代價是資料建模與重試設計必須更早被納入考量。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。