"Aurora-Dsql"
- Aurora PG/MySQL vs Aurora DSQL 取捨:何時 single-region managed 夠用、何時跨到 distributed
Aurora DSQL 不是 Aurora 的升級版而是不同 paradigm;本文聚焦『standard Aurora(single-region managed SQL)什麼時候夠用、什麼時候需要跨到 active-active distributed』的升級門檻決策,切分『怎麼遷』(migrate-to-aurora-dsql)與『DSQL vs Spanner vs CockroachDB 三方選型』(decision-tree)兩個既有 SSoT
- PostgreSQL → Aurora DSQL Migration:PG wire-compatible Distributed SQL 的 Paradigm Shift
Aurora DSQL(2024-12 re:Invent preview / 2025-05 GA)是 AWS 推的 PG wire-compatible *active-active distributed SQL*、跟 self-managed PG / Aurora PG 不同 paradigm(OCC + snapshot isolation + multi-region strong consistency)。Migration 結構是 *protocol drop-in + paradigm shift*:app SQL 不太改、但 transaction retry / extension 缺位 / 多 region 一致性需重設計。本文走 DSQL vs Aurora PG vs self-managed PG 三軸對比、為什麼遷的三條 driver(global write / operational zero-touch / region resiliency)、Type E phased plan、5 production 踩雷(transaction retry 沒處理 / extension 缺位 / sequence throughput 限制 / Aurora PG 直升 DSQL 不可行 / region failover semantic)、跟 PG → Aurora 跟 PG → CockroachDB 對比
- CockroachDB vs Aurora DSQL vs Spanner:撞牆訊號分型 + 七問題決策樹
Distributed SQL 三選一決策樹。先用撞牆訊號分型識別 driver path(DoorDash 單主寫入撞牆 / Netflix Cassandra 缺口 / Hard Rock 合規驅動)、再走七問題(跨雲 / 雲商生態 / 風險預算 / PG 相容 / 管理負擔 / team size / vendor sizing barrier)。PostgreSQL 相容性 audit checklist 4 項、Spanner 100 pu sizing barrier、Hard Rock 「省 10-20 工程師」機會成本警示、Netflix Database Platform Team 規模