本文是 Aurora family 內的決策取捨文章。聚焦 standard Aurora（Aurora PostgreSQL / MySQL，single-region managed SQL） 跟 Aurora DSQL（active-active distributed SQL） 之間的升級門檻判斷。兩個既有 SSoT 不在本篇重複：「PG → DSQL 怎麼遷」見 migrate-to-aurora-dsql；「DSQL vs Spanner vs CockroachDB 三方 distributed SQL 選型」見 aurora-dsql-spanner-decision-tree。本篇只回答「standard Aurora 夠不夠、要不要跨過去」。

多數團隊不需要 Aurora DSQL。Aurora PostgreSQL / MySQL 已經是 managed SQL、storage / compute 分離、跨 AZ 高可用、read replica 擴讀——絕大多數 OLTP workload 在這層就解決了。Aurora DSQL 是 2024-12 re:Invent preview、2025-05 GA 的 不同 paradigm 產品：PG wire-compatible 但底層是 active-active distributed、OCC + snapshot isolation、multi-region strong consistency。它解的是 standard Aurora 解不了 的特定問題，代價是放棄一部分 PostgreSQL 相容性與交易自由度。要不要跨過去，看 workload 是否真的撞到 standard Aurora 的結構上限。

時間錨點：Aurora DSQL 2024-12 preview、2025-05 GA。vendor 能力持續演進、實際決策前以 AWS docs 當前狀態為準。

核心差異：single-writer vs active-active

兩者的根本差異在寫入架構：

standard Aurora 的 storage 層雖然分散，compute 寫入仍是 single writer——這是它的結構上限。DSQL 把寫入也分散，代價是 SQL 相容性縮窄（PG 子集、extension 缺位）與交易語意改變（OCC，衝突要 application retry）。

該跨到 DSQL 的訊號

只有撞到 standard Aurora 結構上限的特定需求，才值得跨 paradigm：

• global write（多 region 都要低延遲寫入）：standard Aurora 跨 region 只有非同步副本、寫入要回到單一 writer region；真正需要多 region active-active 寫入 → DSQL
• single-writer 寫入上限撞牆：寫入量大到單一 writer instance（即使最大 instance class）撐不住、且無法用 sharding 簡單解 → DSQL 的水平寫入擴展
• region resiliency（單 region 失效仍要可寫）：standard Aurora 的跨 region failover 有 RPO/RTO 與寫入中斷；要求單 region 失效時其他 region 仍持續接受寫入 → DSQL active-active
• operational zero-touch：不想管 instance / failover / 容量 → DSQL serverless 模型（但這單項不足以跨 paradigm、要搭配上面的結構需求）

不該跨的訊號（standard Aurora 夠用）

以下情況跨 DSQL 是過度工程、且會付出相容性代價：

• single-region 夠用：寫入集中在一個 region、跨 region 只需要讀副本或 DR → standard Aurora
• 需要 PostgreSQL extension：依賴 PostGIS / pgvector / 特定 extension → DSQL 子集不支援、留 standard Aurora
• 複雜 / 長交易：依賴長交易、複雜多語句交易、特定 isolation 行為 → standard Aurora 的完整交易模型
• 寫入量 standard Aurora 撐得住：single writer 還有餘量 → 不必為「未來可能」預先跨 paradigm

9.C14 Standard Chartered 與 9.C4 DraftKings 是反向佐證：金融帳本 / 博彩這類高一致性、高關鍵 OLTP workload，在 standard Aurora 上就能同時拿到韌性與性能（DraftKings replication lag 降到 10-30ms 級、Standard Chartered 把韌性與性能當單一目標）。它們沒有跨到 distributed SQL——因為 single-region 強一致 + 跨 AZ 高可用已滿足需求。多數金融 OLTP 不需要 active-active multi-region write。

Scope warning：Standard Chartered / DraftKings 的 case 揭露其用 standard Aurora 達成韌性 + 性能（見 storage-architecture）；「它們不需要 DSQL」是本文基於其 single-region 強一致需求的推論、非 case 明文比較 DSQL。引用為「standard Aurora 已足夠多數高一致 OLTP」的訊號、不當 DSQL 對比的 case fact。

升級門檻決策流程

從需求判讀到路徑選擇的流程：

Step 1：確認是不是 global write 需求

寫入是否真的需要多 region 同時低延遲？還是只需要多 region 讀 + 單 region 寫？後者 standard Aurora（+ Global Database 讀副本）就解。

Step 2：確認 single-writer 是否真的撞牆

當前寫入量 vs 最大 instance class 上限、是否已嘗試過 read/write 分離、是否能用 application 層 sharding。撞牆才考慮 DSQL；沒撞牆是過早優化。

Step 3：檢查相容性代價

清點對 PG extension、長交易、特定 SQL 功能的依賴。依賴重 → DSQL 相容性子集會擋路、留 standard Aurora。

Step 4：若決定跨，走既有 SSoT

• 「PG → DSQL 怎麼遷」（protocol drop-in + paradigm shift、transaction retry 處理、extension 缺位）→ migrate-to-aurora-dsql
• 「DSQL vs Spanner vs CockroachDB 哪個 distributed SQL」→ aurora-dsql-spanner-decision-tree

Rollback boundary：跨 paradigm 是高成本決策——DSQL 子集相容性與 OCC 交易模型改變了 application 契約，回退到 standard Aurora 不是改 connection string 就好。決策前用一個非關鍵 workload 試點、確認相容性與 retry 行為，再擴大。

邊界與整合

為什麼這是「升級門檻」而非「遷移」

standard Aurora → DSQL 不是版本升級、是 paradigm 切換。Aurora PG/MySQL 用得好好的，不代表「升級到 DSQL 會更好」——多數情況會更差（失去 extension、交易要改、相容性縮窄）。只有 workload 真的需要 active-active multi-region write 或撞到 single-writer 上限，跨過去才划算。這跟「PostgreSQL major version upgrade」（同 paradigm、向後相容）是完全不同性質的決策。

Sibling 與 cross-link

• storage-architecture — standard Aurora 的 storage 分散但 compute single-writer 的結構上限根源
• global-database-multi-region — standard Aurora 的多 region 方案（非同步副本）、global write 需求前先確認這層夠不夠
• migrate-to-aurora-dsql — 決定跨之後的遷移 playbook（SSoT）
• aurora-dsql-spanner-decision-tree — 三方 distributed SQL 選型（SSoT）
• 替代路由：single-region 夠 → 留 standard Aurora；KV access pattern → DynamoDB
• 跟 Standard Chartered 9.C14 / DraftKings 9.C4 互引：高一致 OLTP 在 standard Aurora 已足夠的訊號

本文是跨 vendor migration playbook、cross-link 到 PostgreSQL（source）跟 Aurora（DSQL 也屬 Aurora family、但 paradigm 不同）。跟 migrate-to-aurora（PG → Aurora PG、protocol drop-in + operational redesign）跟 migrate-to-cockroachdb（PG → CRDB、Type E paradigm shift）對照、本篇是 Aurora 內 PG → DSQL 的 paradigm shift。每階段切換用 migration gate 把關。

時間錨點：Aurora DSQL 在 2024-12 re:Invent preview、2025-05-27 GA。本文 vendor claim 以 2025-2026 公開狀態為準、實際 migration 前請以 AWS docs 為準（feature 持續演進中）。

為什麼遷：Global Write / Operational Zero-touch / Region Resiliency 三條 driver

PG → DSQL 不是「自然演進」、是 application 需求超出 single-primary 模型 時的 paradigm 換軌。三條典型 driver 各自對應一種 application 約束、不是「三選一」、而是「至少其中一條剛性、其他兩條是 bonus」：

反向 driver（DSQL → Aurora PG）也存在：

• 需要 PG extension（pgvector / TimescaleDB / PostGIS / pg_repack）— DSQL 不支援
• Cost：DSQL 比 Aurora PG 貴 2-5x（依 region 數量）
• Single-region OLTP 不需 distributed transaction 的 overhead

結構：Protocol Drop-in + Paradigm Shift

DSQL 是 PG wire-compatible（用 psql 連得上）、但內部是 distributed SQL engine：

Paradigm shift 的核心：

1. Transaction semantic：DSQL 用 OCC（Optimistic Concurrency Control）+ strong snapshot isolation、跟 PG 預設 read committed / repeatable read snapshot 不同 — 同 row 有 concurrent write 時、commit 階段才偵測衝突 + abort、application 要 handle 40001 serialization_failure
2. No extension：PostGIS / pgvector / TimescaleDB / pg_partman 都不能用、依賴這些 feature 的 application 要拆出去
3. No connection pool stateful：DSQL 內建 connection pool、application 不能依賴 session state（temp table / prepared statement / advisory lock）

Schema gap：PG 對 DSQL 限制

DSQL 是 PG-compatible subset、有幾類功能不支援：

Migration 必做 schema audit：

 1-- 找所有 extension 依賴
 2SELECT * FROM pg_extension;
 3
 4-- 找 materialized view
 5SELECT schemaname, matviewname FROM pg_matviews;
 6
 7-- 找 sequence
 8SELECT * FROM pg_sequences;
 9
10-- 找 FDW
11SELECT * FROM pg_foreign_server;
12
13-- 找 trigger
14SELECT * FROM pg_trigger WHERE NOT tgisinternal;

任何項目命中、都是 migration blocker。

Operational Redesign

跟 self-managed PG 或 Aurora PG 比、DSQL operational model 大幅簡化但語意不同：

Migration 流程：Type E Phased Plan

Type E paradigm shift 的 phased plan、跟 migrate-to-cockroachdb 結構類似：

Phase 1：Schema / Application Audit

• 跑 schema audit（extension / MV / FDW / sequence / trigger）
• 識別 application 哪些 query / transaction pattern 需重設計
• 估算 能直接遷的 % vs 需重寫的 %、典型 60-80% / 20-40%

Phase 2：Application 改造（不上 DSQL、先在 PG 跑）

• 加 transaction retry middleware（攔截 40001、exponential backoff）
• 用 UUID 替代 serial / bigserial
• 移除依賴 LISTEN/NOTIFY 的功能（改 SQS / EventBridge）
• 移除 materialized view（改 application-side cache 或 incremental ETL）
• Stored procedure 改 application code
• 在 PG 上跑 staging、確認新 application code 還對

Phase 3：DSQL Cluster 建立 + Schema 遷

• DSQL cluster create
• DDL apply（subset of PG schema、無 extension）
• DMS（Database Migration Service）initial load + ongoing replication
• 兩邊跑 shadow traffic、比對 query 結果

Phase 4：Cutover

• Application 切 connection string 到 DSQL
• 保留 PG read-only 一週、出狀況 rollback
• Monitor 40001 retry rate、scaling event 行為

Phase 5：多 region 拓展（如適用）

• 加第二 region endpoint
• Application 改 multi-region routing（latency-based）
• Test region failure / network partition 行為

5 個 Production 踩雷

Case 1：Transaction Retry 沒處理

情境：PG 上「兩個 transaction 都 update 同 row」走 lock + wait；DSQL 同情境一個會收 40001 serialization_failure、application 沒 catch、user 看到 500 error。

修法：

• DAO 層加 retry middleware：catch 40001 + exponential backoff（jitter）
• Retry 上限 3-5 次、超過回 4xx 給 user
• Transaction 內不要做 side effect（API call / message send）、retry 會重做

1def with_retry(fn, max_attempts=5):
2    for attempt in range(max_attempts):
3        try:
4            return fn()
5        except SerializationError:
6            if attempt == max_attempts - 1:
7                raise
8            time.sleep((2 ** attempt) * 0.05 + random.random() * 0.05)

Case 2：Extension 缺位、Feature 整段掉

情境：production PG 用 pgvector 做 RAG search、PostGIS 做 store locator、TimescaleDB 做 metrics — 切 DSQL 後三 feature 全沒。

修法：

• 不要直接遷、評估 which extension is load-bearing
• pgvector → 外掛 Pinecone / Weaviate 或保留 PG 跑 vector workload
• PostGIS → 保留 PG 跑 GIS workload
• TimescaleDB → 切 Amazon Timestream 或保留 PG
• DSQL 只放 不依賴 extension 的 transactional core

實務常見拓撲：DSQL 跑 transactional core、附 PG（vector） + PG（GIS） + Timestream（metrics）。

Case 3：Sequence 高吞吐撞 Coordination Overhead

情境：SERIAL / GENERATED AS IDENTITY PK 在 DSQL 用、insert 量 1000+/s 時 sequence nextval 變成 bottleneck、insert latency 從 5ms 跳到 80-100ms+。

DSQL 有支援 sequence、但不是「local atomic counter」、是分散式 counter — 每次 nextval 需跨 region coordination 保證唯一性。低吞吐 OK、高吞吐撞牆。

修法：

• 高吞吐表 PK 換 UUID v7（time-sortable、無 coordination）：gen_random_uuid() 或 application-side UUID v7 library
• 或 application-side ULID（time-sortable、12-byte 緊湊）
• 完全避免依賴「連續 integer PK」的 application 邏輯（reporting / paging 改用 ORDER BY created_at, id）

1-- 換 UUID PK
2CREATE TABLE orders (
3    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
4    ...
5);

低吞吐表（settings / config）保留 sequence OK；high-volume transactional 表（orders / events）建議 UUID。

Case 4：Aurora PG 直升 DSQL 想當 in-place

情境：team 以為「Aurora PG 跟 Aurora DSQL 都是 Aurora、應該能直升」、申請 cluster modify、發現完全是兩個 service。

修法：

• 不是 in-place upgrade、是 full migration（DMS + cutover）
• 把 DSQL 當完全新的 cluster type、走 Phase 1-4 完整流程
• Aurora PG → Aurora DSQL 不比 PG → CRDB 容易、wire-compatible 只解 application connect 問題、不解 schema / paradigm 差異

Case 5：Region Failover Semantic

情境：team 以為「DSQL multi-region 等於高可用」、設計時假設「整 region 掛還是能寫」、實測發現「網絡分割時 DSQL 走 quorum、可能 reject write」。

DSQL 是 strong consistency 多 region、CAP 取 CP（不是 AP）— network partition 時部分 region 會拒絕 write、不是「永遠可寫」。

修法：

• 設計 application 要 handle write reject（partition recovery 後 retry）
• 不要把 DSQL 當「永遠可寫」的 cache 或 queue 用
• 真要 AP 行為、用 DynamoDB（global table）

Capacity 規劃

DSQL 計費跟 Aurora PG 差很多：

實務 cost：Aurora PG db.r6g.4xlarge multi-AZ 月 ~$2000 → DSQL 同 workload ~$5000-10000（依 region 數）。

何時 DSQL cost 划算：

• 多 region active-active 需求剛性（不是 nice-to-have）
• Operational FTE 節省超過 cost 差
• Burst workload（DSQL 自動 scale、Aurora PG 預配置 idle 期浪費）

跟既有 Migration Playbook 對比

Aurora DSQL vs CockroachDB 選擇：

選 DSQL：已綁 AWS、不想管基礎設施、需 PG semantic。 選 CRDB：跨雲、有自管 SRE、需要 fine-grained control。

相關連結

• migrate-to-aurora：Aurora PG 對比（Type C）
• migrate-to-cockroachdb：CRDB 對比（Type E）
• extension-ecosystem：DSQL 不支援的 extension
• connection-scaling：DSQL 內建 pool 跟 PgBouncer 對比

下一步

• 看 Aurora overview 認識 Aurora family
• 看 migrate-to-cockroachdb 對比另一個 Type E migration
• 回 PostgreSQL overview 看全圖

本文是 DB4 distributed SQL 選型的 entry point deep article — 讀者進來時還沒決定哪個 vendor、甚至還沒釐清「我是不是該換 distributed SQL」。本文先用 撞牆訊號分型 幫讀者識別自己屬哪條 driver path、再進三軸 vendor 對比、最後落到 team size + sizing 邊界檢查。配合 CockroachDB vendor overview + 1.11 全球分散式 OLTP 閱讀。寫作參照 vendor deep article methodology。

為什麼先講 driver path、不直接比 vendor

團隊評估「全球分散式 OLTP 三選一」時最常見的源頭錯誤：先比 vendor、再回頭問「我為什麼要 distributed SQL」。三家 vendor 文件都說「跨 region 強一致 SQL」、看不出實際取捨；做錯選擇後遷移成本極高。

正確順序應該反過來：先識別 自己為什麼要評估 distributed SQL、再進 vendor 比較。三條 driver path 各自的訊號、適配 vendor、決策路徑都不同 — 不識別 driver path 直接比 vendor 是源頭錯誤。

讀者進來最常問的問題（多數會問錯順序）：

• 我是不是真該換 distributed SQL、還是 Aurora / Cloud SQL 還能撐？
• Spanner 在 Google 跑了 10 年、CockroachDB 跟 DSQL 比較新、成熟度差多少？
• 我有 PostgreSQL 應用、三家相容性差在哪？
• 跨雲是硬需求還是被 fear 推的？
• DSQL 2024 才 GA、production 風險多大？
• 我團隊 50 人能不能養 self-managed CockroachDB？
• Spanner 100 pu 起跳對我中小 PG workload 划算嗎？

7 題本文都會回答、但先回答「你是哪條 driver path」這個前置問題 0。

三條 driver path 的 case anchor

• 9.C39 DoorDash：Aurora Postgres 1.636 M QPS single-primary 撞牆 → 換 multi-primary、PostgreSQL wire 相容降低遷移阻力（F4.1 / F4.2 / F4.4）
• 9.C40 Netflix：Cassandra eventual consistency 撐不住 transactional → 補 distributed SQL、self-managed 380+ cluster + Database Platform Team（F4.6 / F4.9）
• 9.C41 Hard Rock Digital：Wire Act 合規驅動 + 50 人 tech team + Outposts 混合部署（F4.10 / F4.14）

對照 9.C10 Spanner planetary scale 提供 Spanner ground truth（含 sizing barrier、F3.16）、9.C14 Standard Chartered 提供 Aurora 受監管金融的另一條路徑、9.C4 DraftKings Aurora financial ledger 提供 Aurora 內 business sharding 路徑（不換引擎）。

撞牆訊號分型：你的 driver path 是哪一條（前置問題 0、F4 Frame 1）

讀者進來前先回答：你 為什麼 要評估 distributed SQL？三條 driver path 各自的訊號、適配 vendor、決策路徑都不同。

Path A — single-primary 寫入撞牆（9.C39 DoorDash 路徑、F4.2 + F4.6）

訊號：

• 寫入量持續成長、Aurora / RDS / Cloud SQL primary CPU + WAL flush rate 接近上限
• 轉折點 不是 IOPS、是 primary CPU + WAL flush rate（F4.2、DoorDash 策略段 1）
• 已嘗試 vertical scale primary、撞 instance ceiling

DoorDash concrete reference：2020-04-17 高峰 > 1.636 M QPS、multi-hour outage（觀察段表格）。Scope warning（F4.1、case 自帶警示）：1.636 M QPS 是 Aurora 撞牆的痛點 — 不是「CockroachDB throughput claim」、case 沒揭露遷移後單一 CockroachDB cluster 的峰值、只說「跑更多 cluster、alert volume 反而下降」。

適配 vendor：CockroachDB / Aurora DSQL / Spanner 都解、選擇看其他軸。

Path B — eventual consistency 缺口（9.C40 Netflix 路徑、F4.6）

訊號：原本用 Cassandra / Riak / DynamoDB eventual consistency、遇到 5 條件並存 需求：

1. multi-active topology（多 region 都可寫）
2. global consistent secondary index（跨 region 一致的二級索引）
3. global transaction（跨 row / 跨 region 的 ACID）
4. open source
5. SQL

Cassandra 在 transactional 場景下 湊不齊 這五項。Netflix 2019 評估後選 CockroachDB（5 條件 case 直接列出、判讀段 1）。具體場景：Studio Cloud Drive（強一致 metadata + 全球可寫）、Open Connect 控制平面、Spinnaker（持續交付）、Maestro（ML / 資料 workflow）、Gaming 控制平面。

適配 vendor：CockroachDB（open source + SQL 兩條件硬卡）、Spanner（若 GCP-only 可放鬆 open source 要求）。

Path C — 合規驅動的地理邊界 + 跨 boundary 業務邏輯需求（9.C41 Hard Rock 路徑、F4.10）

訊號：

• 法規要求資料留某地理邊界（Wire Act 跨州、GDPR 跨國、各州博彩牌照）
• 同時 業務邏輯需要跨 boundary（跨州統一帳戶 / 跨州 reporting / 欺詐偵測）

Hard Rock concrete reference：跨 8 州（AZ / IN / TN / FL / OH / IL / NJ / VA）+ AWS Outposts + 邏輯一個 cluster（觀察段表格）。詳細 schema 配置見 locality-aware schema。

適配 vendor：CockroachDB（locality + placement + Outposts）、Spanner（GCP region 內 placement、無 Outposts 等效）、Aurora DSQL 跨 region 強一致但 Outpost 部署現階段未完整覆蓋。

不該換 distributed SQL 的訊號

• single-region OLTP 已足夠
• 寫入量未撞 single-primary 天花板（Aurora db.r6g.16xlarge 還沒滿）
• 無跨 region 業務需求
• 無跨 boundary 合規需求

→ PostgreSQL / Aurora 足夠、distributed SQL overhead（寫入 2-5x latency、ops 複雜度）不划算。對應 9.C4 DraftKings 走 Aurora + application sharding 的路徑、不換引擎也能解單主寫入瓶頸。

數字口徑：本段「2-5x latency」屬通用工程估算（Raft / Paxos round trip 跟 single-leader replication 的 latency ratio）、case 未直接揭露對照數字、實際值依拓樸 / 寫入大小 / 一致性層次而異、應該以自家 benchmark 驗證。

核心機制：三軸 vendor 對比

完成 driver path 識別後、進三軸 vendor 對比。

軸 1 — 部署 topology

Path C 場景（Hard Rock Outposts hybrid）強制走 CockroachDB — 另兩家不提供等效部署。

軸 2 — Managed 成熟度

Scope warning（來源分層）：3 case 都沒揭露成熟度比對、本軸依 case + vendor 公開文件 + 外部知識合成：

• Spanner：10+ 年 Google 內部 + 外部 GA（依 9.C10 case + Google research paper、屬 vendor 公開文件 + dogfood frame）
• CockroachDB：自管 + Cockroach Cloud（managed 較新、依 Cockroach Labs 公告）
• Aurora DSQL：2024-05 GA（依 AWS 公告）

引用紀律：「Spanner 10+ 年」是 vendor 公開 + Google dogfood 的合成、不是 case 直接揭露的 production stability 數字。Aurora DSQL「2024-05 GA」屬 AWS 公開公告、production case ground truth 還在累積。引用時要明示來源層次。

軸 3 — SQL 相容性

PostgreSQL 相容性 audit checklist 4 項（F4.4、DoorDash 揭露）

DoorDash case 揭露 PG wire protocol-level 相容、SQL 行為「仍要驗證」。把這個警語展開成 audit checklist：

1. Serializable default：CockroachDB default SERIALIZABLE、PG default READ COMMITTED → application transaction 行為差異（細節見 transaction retry pattern）。Aurora DSQL 預設行為要看 AWS 公告。
2. Retry semantics：CockroachDB 發 40001 serialization_failure、application 必須包 retry loop。PG / Aurora 預設不需要、application 沒 retry middleware。Aurora DSQL 比照 CockroachDB 模型、需要 retry loop。
3. Partial index：CockroachDB 支援程度與 PG 有差異、application 用到的 partial index 要逐一驗證。Spanner GoogleSQL 跟 PG 行為不同。
4. 其他 SQL 行為：sequence、auto-increment、stored procedure、custom function、extension 等都需 case-by-case audit。

引用紀律：DoorDash 揭露的是「PG wire protocol-level 相容、SQL 行為要 audit」這個 fact、本章把 audit 內容展開成 4 項屬通用工程議題、不是 DoorDash case 直接揭露。

Consensus 機制差

三家共識機制的差異直接決定 external consistency 的實作路徑：Spanner 用 TrueTime + commit-wait 撐 external consistency；CockroachDB 用 HLC + max-offset 撐 linearizability、不保證 external consistency；Aurora DSQL 走類 Spanner 路徑但細節未完全公開。三家 multi-region 配置都吃 Cross-Region Quorum 的物理 latency tax。詳細機制見 HLC + Raft consensus。

Pricing model 差

• CockroachDB self-managed：node × resource、cluster 至少 3 node
• Cockroach Cloud / Spanner / DSQL：consumption-based（read / write / storage / network）

Sizing barrier 邊界（F3.16、9.C10 Spanner case 揭露）

Spanner 100 processing unit 起跳是 最小 footprint — 對中小 PostgreSQL workload 是 cost 邊界：

• workload 月寫入若只夠 PG db.m6g.large 級別、付 Spanner 100 pu 起跳 cost 不對
• CockroachDB 最小 3 node、storage / compute 線性 — 中小 workload 較友善
• Aurora DSQL consumption-based 無 minimum、中小 workload 最友善（但 production case 累積較少）

判讀：sizing barrier 是 vendor 強制最小 footprint、不是「啟動成本」— 即使 workload 縮小、minimum 不會降。中小 PG workload 直接套 Spanner = 付不必要的 minimum cost。

對應 distributed SQL 卡、quorum 卡、vendor lock-in 卡。

決策樹：七問題

前置問題 0 在 撞牆訊號分型 段已回答（你的 driver path 是 A / B / C 哪一條）。以下進三家 vendor 對比的七個問題。

問題 1：是否硬需求跨雲 / on-prem？

• Yes → CockroachDB（唯一選項；對應 9.C40 Netflix 跨 AWS region、9.C41 Hard Rock AWS Outposts 混合）
• No → 進問題 2

跨雲是 硬需求 而不是 fear-driven 訊號：

• 真硬需求：法規明文跨雲、acquisition 後多雲整合、vendor risk 政策強制
• fear-driven：「萬一 AWS 全球 outage」（多數公司實際走 single-cloud、跨雲 portability premium 卻沒實際 multi-cloud 部署）

數字口徑：本段「多數公司 single-cloud」屬通用工程估算、case 未揭露明確比例、實際分佈依產業 / 監管 / 規模而異。判斷自己是否需要跨雲時、看具體規範跟 risk 條款、不直接套通用比例。

問題 2：已在 AWS 還是 GCP 還是中立？

• AWS 深 → Aurora DSQL（操作模型對齊、PostgreSQL 相容）
• GCP 深 → Spanner（10 年成熟、Google 內部驗證）
• 中立 / 多雲 → CockroachDB（可 portable）

雲商生態深度判讀：IAM / VPC / monitoring / cost mgmt 已深度整合 AWS → Aurora DSQL 整合阻力低；同樣道理 GCP → Spanner。

問題 3：production 風險預算？

• 低（金融 / 醫療）→ Spanner（最成熟）或 CockroachDB（>5 年外部 production case）
• 中 → 三者皆可
• 高（願意當 early adopter）→ Aurora DSQL（2024 GA）

風險預算對應的不是「會不會掛」、是「邊界 case 文件成熟度 + production troubleshooting case 量」。Aurora DSQL 2024 GA、production case 累積中、邊界 case 仍在被發現。

問題 4：PostgreSQL 相容性是 hard requirement？

• Yes（既有 application）→ CockroachDB 或 Aurora DSQL（兩者都做 PG 相容、但走 audit checklist 驗證 SQL 行為）
• No → Spanner（GoogleSQL 也可）

PG hard requirement 訊號：application 用 PostgreSQL-specific feature（partial index、JSONB operator、PostGIS、PG extension 生態）、ORM / driver 深度綁 PostgreSQL wire。

問題 5：管理負擔誰承擔？

• 自管 → CockroachDB（唯一可自管）
• Managed → 都行、依雲商生態

自管 vs managed 不只是「省人月」、是「邊界 case 出現時誰修」— managed 的 vendor 負責、自管的自己負責。

問題 6：team size 是否撐得起 self-managed（F4.14、9.C41 Hard Rock + 9.C40 Netflix 揭露）

distributed SQL 的 ops 槓桿來自系統內建 Raft / placement 把「DBA 養單區、跨區 sync 養運維」工作量壓進系統內。

Hard Rock 50 人 tech team 估「若用 PostgreSQL 需多加 10-20 工程師」（觀察段表格 + 策略段 4）。Case 自帶警示：「省了 10-20 工程師」是 機會成本（沒招那麼多 DBA）、不是 節省支出（已 hire 後解雇）。引用必須明示口徑：

• 正確：「distributed SQL 對小團隊的 ops 槓桿 = 不必招那麼多 DBA」
• 錯誤：「上 CockroachDB 可裁員」、「節省人月支出」

Self-managed 規模化的另一極：Netflix 養 380+ cluster 需要 專屬 Database Platform Team（含 backup / upgrade / incident response / capacity review、F4.9）。沒這量級團隊直接 self-host 大規模 cluster 是 ops 自殺、Cockroach Cloud 才是合理路徑。判讀訊號：「self-managed cluster 數量 vs 平台團隊規模」轉折點 case 沒講具體閾值、引用時不可宣稱閾值、但方向清楚：

• team size 小（< 100 人 tech team、無專屬 DB platform team）→ Cockroach Cloud / Spanner / DSQL（managed）優先
• team size 大 + 有專屬 DB platform team → self-managed CockroachDB 可考慮
• team size 中等但要 self-host 大規模 cluster → 評估專屬 platform team 投資後再決定

問題 7：sizing 是否撐得起 vendor minimum（F3.16）

• Spanner 100 processing unit 起跳對中小 PG workload 是成本門檻、月寫入 < 某 baseline 時付 Spanner 起跳費不划算
• 中小 workload 但需 multi-region 強一致 → CockroachDB 3 node 起 / Aurora DSQL consumption-based 較友善
• 大 workload（已過 single-primary 撞牆訊號）→ 三家皆可、進問題 1-6 再篩

Cluster boundary 顆粒：per-app cluster vs 邏輯一個 cluster（CockroachDB cluster boundary SSoT）

位置標：本段是 _module-outline.md Section G「CockroachDB cluster boundary 顆粒」的 SSoT 主寫段、是 已選 CockroachDB 後 的拓樸決策（跟前面七問題 vendor 選擇分流）。其他 vendor cluster boundary 議題不在本段重複展開 — Aurora fleet 治理（business sharding / 200 cluster 模式）見 aurora/read-replica-scaling、MongoDB blast radius 切多 cluster（Toyota 20 DB 模式）見 mongodb/shard-key-selection。

選完 vendor 還有一個正交的拓樸決策：CockroachDB cluster 的「顆粒」要切多細。一個微服務一個 cluster（per-app）、還是多個微服務共用一個邏輯 cluster（shared / 邏輯一個 cluster）。這條軸的判讀獨立於跨雲 / 風險預算 / 管理負擔等七問題、是 cluster 拓樸 議題、不是 vendor 選擇議題。判讀核心是 blast radius 的取捨 — 是把故障半徑限縮在單服務（per-app）、還是接受邏輯 cluster 內事故跨業務影響但換 transactional cross-domain 能力（邏輯一個 cluster）。本段是 CockroachDB cluster boundary 顆粒的主寫位置、其他 sibling 文章（hlc-raft-consensus、survival-goals、locality-aware-schema）cross-link 不重複展開。

Per-app cluster（Netflix 380+ 路徑、F4.7 揭露）

每個微服務 / 每個業務邊界各自獨立 cluster。Netflix 揭露的具體形貌：380+ cluster、每個 cluster 規模小（屬「artery of small DBs」哲學、不是巨型 DB）、每個服務 own 自己的 schema 跟容量。

判讀訊號：

• 服務之間資料 硬隔離（compliance / blast radius / 不同 SLA tier）— 共用 cluster 一旦 schema migration / hot range 出事、影響面跨服務
• 跨服務 query 需求低（沒有 cross-domain JOIN 場景）
• 容量規劃可以 per-cluster（每個服務自己估、不需共池）
• 有專屬 Database Platform Team 養 cluster lifecycle（backup / upgrade / incident response / capacity review、F4.9）— ops surface area 隨 cluster 數 線性成長

代價：ops surface area 大、每個 cluster 都要獨立 upgrade / monitoring / capacity review。沒這量級平台團隊直接 self-host 380 cluster 是 ops 自殺。

邏輯一個 cluster（Hard Rock 路徑、F4.10 揭露）

業務邏輯上是 一個 CockroachDB cluster、物理上跨多地理 placement（locality + replication zone 把 range 釘到特定 region / AZ / Outpost）。Hard Rock 揭露的具體形貌：跨 8 州 + AWS Outposts、邏輯一個 cluster、跨州統一帳戶 / 跨州 reporting / 欺詐偵測在同一 cluster 內做 transactional query。

判讀訊號：

• 跨服務 / 跨地理需要 transactional query（跨州統一帳戶、跨業務統合 reporting）— 拆獨立 cluster 會破壞業務邏輯
• 合規顆粒 細 到 region / 州 / AZ、但 不要求 完全隔離 cluster（Wire Act 要求州內運算、但允許跨州 application 邏輯）
• Team size 中小（Hard Rock 50 人 tech team）、ops surface area 集中比攤平好管
• 容量規劃集中、跨服務資源共享（不同服務的 range 可以 colocate 同 cluster）

代價：cluster 內複雜度高（要設計 placement / locality / replication zone 把 range 釘對地方）、blast radius 是 整個邏輯 cluster、cluster 級事故影響跨業務。

兩條路徑的判讀軸

判讀順序：先問「跨服務 query 需要 transactional 嗎」— Yes 偏邏輯一個 cluster、No 進下一條；再問「服務之間 SLA / compliance 是否硬隔離」— Yes 偏 per-app、No 看 team / ops 槓桿。

跟 Aurora fleet 治理的本質差異

Aurora fleet 治理 SSoT（read-replica-scaling 邊界段）展開的是 Aurora cluster 之間 怎麼拆（business sharding / blast radius / read fanout），cluster 是 single-primary 抽象、拆 cluster 是 繞過 single-primary 上限。

CockroachDB cluster boundary 的問題不一樣 — CockroachDB 本身就是 distributed、單 cluster 內可橫向擴展、cluster boundary 是 業務 / 合規 / blast radius 邊界、不是繞 single-primary。

兩條路徑的 拆與不拆 動機本質不同。Aurora 拆是 被迫（單 cluster 撐不住）、CockroachDB 拆是 選擇（單 cluster 撐得住、拆是為了治理）。

跨 vendor 路徑對照

• Aurora fleet（DraftKings 200 cluster）— business sharding 繞 single-primary 上限、每 cluster 仍可多 service、平均負載低（9.C4 case 揭露單 cluster ~80 ops/sec、200 cluster 加總 17K ops/sec）
• CockroachDB per-app（Netflix 380+）— 微服務級拆 cluster、artery of small DBs、需要專屬 Database Platform Team；單 cluster 內 Range Sharding + Leaseholder 負責內部 scaling
• CockroachDB 邏輯一個（Hard Rock）— 跨地理單一 cluster、locality + placement 撐合規 + transactional 跨域、本地化讀靠 Follower Read 降低跨 region cost
• CockroachDB fleet per-jurisdiction（Standard Chartered）— 每監管市場一個 cluster、合規 禁止 跨市場資料流動時的 forced pattern、跟 Hard Rock 對照（合規顆粒粗到要拆 vs 細到能用 placement）

進階閱讀：合規驅動的 cluster boundary 選擇見 locality-aware-schema；單 cluster 容量規劃見 hlc-raft-consensus 容量與觀測段。

失敗模式：常見錯配

過度 fear AWS / GCP lock-in

承接 問題 1：是否硬需求跨雲 段的 fear-driven 訊號（多數場景單雲、跨雲是想像中需求）— 把 fear 當硬需求選 CockroachDB，付 portability premium（自管 ops + Cockroach Cloud 較新）卻沒實際 multi-cloud 部署，結果付的是 lock-in 保險、實際沒用上。

判讀：跨雲訊號要 具體場景（acquisition 後整合 / 法規明文 / vendor risk 政策強制）、不是 fear。

低估 DSQL 成熟度風險

2024-05 GA、production case 少、邊界 case 文件不全 — early adopter 才適合。production 風險預算低的場景（金融 / 醫療 / 合規嚴格）不應該選最新 GA 的服務。

Spanner 假設 PostgreSQL 全相容

Spanner PostgreSQL interface 是 子集、部分 PostgreSQL feature 不支援。應用 migration 仍需 audit、不可直接 lift-and-shift。

Self-managed CockroachDB 低估 ops cost（9.C40 Netflix concrete reference、F4.9）

Raft / backup / upgrade / monitoring 自管比 PostgreSQL 複雜、DBA bandwidth 沒到位變 disaster。Netflix 養 380+ cluster 需要 專屬 Database Platform Team — 含 backup、upgrade、incident response、capacity review。

判讀訊號：「self-managed cluster 數量 vs 平台團隊規模」轉折點 case 沒講具體閾值、引用時不可宣稱閾值、但方向清楚 — 小規模 self-managed 不需要、大規模一定需要、之間有 grey zone 要實際評估團隊能力。

用 distributed SQL 解 single-region OLTP

90% 場景 PostgreSQL / Aurora 夠用、distributed SQL overhead 是 2-5x latency（Raft round trip 額外成本）。沒撞 single-primary 寫入上限的情況下、上 distributed SQL 是付不必要的 latency premium。

合規邊界誤判

受監管市場可能 不能 用任何跨境 distributed SQL（Standard Chartered 模式）、要拆每市場獨立 cluster。反過來、合規顆粒小（跨州 vs 跨國）+ 跨 boundary 業務邏輯需求高（跨州統一帳戶）時、Standard Chartered fleet 拓樸不適合、需走 Hard Rock locality + placement 路徑（細節見 locality-aware schema）。

Sizing barrier 誤判（F3.16）

中小 PG workload 直接套 Spanner 100 pu 起跳、付的是不必要的 minimum cost。中小規模的硬一致 multi-region workload、CockroachDB 3 node / Aurora DSQL consumption-based 更划算。

Team size 誤判（F4.14）

把「省 10-20 工程師」當已 hire 後可裁員的節省支出、實際是 機會成本（沒招那麼多 DBA）。上 CockroachDB 不代表可裁掉現有 DBA — 現有 DBA 反而要轉型成 distributed SQL 運維。

容量與觀測

三家共同 metric

• write QPS
• cross-region latency p99
• storage growth
• replica lag（CockroachDB Raft / Spanner Paxos / DSQL replica）

觀測黑箱程度

• CockroachDB Console：暴露 Raft / range / leaseholder 細節、observability 細
• Spanner / DSQL：managed、metric 經 GCP Cloud Monitoring / AWS CloudWatch、observability 黑箱程度高 — 邊界 case troubleshooting 仰賴 vendor support

容量公式

write QPS × replication factor × cross-region latency = required node / capacity。中小 workload 撞 vendor minimum 才是真實 cost 下界。

Cost signal

三家定價模式不同、cross-region traffic 對 cost 影響都大：

• CockroachDB self-managed：node × resource、可控但要自運維
• Spanner：100 pu minimum + consumption、適合穩定 workload、中小 burst 不划算
• Aurora DSQL：consumption-based、burst 友善、長期穩定 workload 累計可能比 Spanner 高

回路徑

• 9.6 容量規劃模型
• 1.11 全球分散式 OLTP 完整對比

邊界與整合

Sibling deep articles

• HLC + Raft consensus（軟體時鐘 vs TrueTime）
• locality-aware schema（locality model 對比）
• survival goals（HA model 對比）
• transaction retry pattern（application contract 重塑）

Sibling 跨 vendor

• Aurora vendor overview（async cross-region、不是 distributed SQL）
• Spanner vendor overview 對照頁
• PostgreSQL vendor overview（單區 OLTP fallback）

Migration playbook

• PG → CockroachDB
• PG → Aurora DSQL

1.x 章節互引

• 1.11 全球分散式 OLTP 上游
• vendor lock-in 卡
• distributed SQL 卡

何時不用本文

• single-region OLTP 已夠（90% 場景）→ 用 PostgreSQL / Aurora、不必走 distributed SQL
• 無 multi-region requirement、無跨 boundary 合規需求 → 同上
• workload 規模未撞 single-primary 寫入上限 → 走 Aurora vertical scale + read replica 即可

相關連結

• CockroachDB vendor overview
• 9.C39 DoorDash（Path A — single-primary 寫入撞牆）
• 9.C40 Netflix（Path B — Cassandra 缺口、Database Platform Team）
• 9.C41 Hard Rock Digital（Path C — 合規驅動 + team size 槓桿）
• 9.C10 Spanner planetary scale（Spanner ground truth + sizing barrier）
• 9.C14 Standard Chartered（合規邊界 anti-recommendation）
• 9.C4 DraftKings（Aurora sharding 不換引擎路徑）
• 1.11 全球分散式 OLTP
• distributed SQL 卡 / vendor lock-in 卡 / quorum 卡
• 官方：Cockroach Labs Documentation / Spanner Documentation / Aurora DSQL Documentation