本文是 CockroachDB vendor overview 的 implementation-layer deep article。Overview 已界定 CockroachDB 在 distributed SQL 譜系的定位、本文聚焦 HLC + Raft + range + leaseholder 四層機制 — 解釋為什麼 distributed SQL 的 latency / 容量曲線跟 PostgreSQL single-primary 完全不同、以及怎麼從 production 訊號倒推它對團隊的成本結構。寫作參照 vendor deep article methodology。

為什麼這篇先講 HLC + Raft

團隊評估 CockroachDB 替代 PostgreSQL streaming replication 時、會同時看到兩個訊號：「跨 region 強一致」很吸引人、「每次寫都經過 Raft majority」又讓人害怕。前者是賣點、後者是成本結構 — 不先把 HLC / Raft / range / leaseholder 拆清楚、後面講 survival goal、locality、transaction retry 都會卡在「為什麼這個機制存在」這層。

讀者最常問的三題：

• Spanner 用 TrueTime 原子鐘做線性化、CockroachDB 沒硬體時鐘怎麼保證 ordering？
• Raft 每次寫要等 majority ack、不是比 PostgreSQL 慢得多？
• HLC clock skew 超出容忍區間時會發生什麼？節點隨機 panic 嗎？

三題都不只是 spec 問題、而是 production 容量規劃跟 incident 訊號的根本前置。

問題情境最常見的 trigger：9.C39 DoorDash 在 2020-04-17 高峰 Aurora Postgres 撞到 1.636 M QPS、multi-hour outage。這個數字是 Aurora 在那個時間點撞牆的痛點、case 自己警示「不是 CockroachDB 撐到 1.636 M QPS 的 throughput claim」。case 沒揭露遷移後單一 CockroachDB cluster 的峰值、只說「跑更多 cluster、alert volume 反而下降」。要把 CockroachDB 當寫入容量解法評估、就得先理解 Raft per range 怎麼把寫入從 single-primary 分散到多 node。

9.C40 Netflix 則提供另一條訊號：380+ cluster / 60+ multi-region、最大單區 cluster 60 nodes / 26.5 TB。這個規模證明 Raft 維運在 production 可承擔、但也揭露容量規劃顆粒不是「全公司一條容量曲線」、是「每 cluster 各自規劃」— artery of small DBs。

核心機制：HLC + Raft + range + leaseholder 四層

CockroachDB 的線性化保證來自四層機制疊加、缺一層都解釋不通實際 latency / failure 行為。

HLC：軟體時鐘把 wall clock + logical counter 混在一起

Hybrid Logical Clock 結合 physical time（NTP 同步的牆鐘）跟 logical counter（單調遞增的事件序號）、給每個事件一個 (physical, logical) timestamp。對比 Spanner TrueTime 直接靠 GPS + atomic clock 給「時鐘 uncertainty bound」、CockroachDB HLC 不依賴硬體、用軟體保證「節點之間時鐘最多差 max-offset（default 500ms）、超過就 panic」。

1Node A 收到 write at wall=12:00:00.123, last_seen=12:00:00.100
2  → HLC = (12:00:00.123, 0)
3
4Node A 收到 RPC from B at wall=12:00:00.140, B.HLC=(12:00:00.200, 5)
5  → A 跳到 B 的 physical (12:00:00.200)、logical = 6
6  → HLC = (12:00:00.200, 6)

HLC 的契約 只要節點間時鐘差不超過 max-offset、所有 transaction 仍是 linearizable。production 必跑 NTP / chronyd — 一旦本機時鐘飄超過 500ms、節點自動 panic 保護 cluster 一致性、不會發出錯誤 commit。

跟 Spanner TrueTime 對比：

兩條路徑解同一個 event ordering 問題、用不同 trade-off。CockroachDB 把硬體成本換成軟體 max-offset 容忍度、結果是「可以跨雲跨 on-prem 跑、但 NTP 維運是必要條件」。

Raft：每個 range 一個獨立的 majority consensus group

Raft 把寫入流程切成 propose → replicate to majority → commit 三段。每個 range 維護自己的 Raft group、預設 3 replica、寫入要至少 2 個 replica ack 才能 commit。

1Client → Leaseholder (Raft leader)
2   1. Propose log entry (write intent)
3   2. Replicate to 2 follower replicas
4   3. Wait for majority ack (本身 + 1 個 follower)
5   4. Commit、apply to state machine
6   5. Reply to client

關鍵差異跟 PostgreSQL streaming replication 比：

• PostgreSQL primary：1 個節點 ack 就 commit（async replication）、replica 可能落後
• PostgreSQL sync replication：1 個 standby ack 才 commit、但仍是「primary 是 single point of write」
• CockroachDB Raft：majority（2 of 3）ack 才 commit、任何 replica 都可以是 leaseholder、寫入分散到所有節點

寫入 latency 因此 結構性 高於 PostgreSQL — 多了一次 cross-node round trip。但寫入 吞吐 可以線性擴展、因為不同 range 的 Raft group 跑在不同節點上。

Range：把 key space 切成 ~512 MB 的可分裂單位

CockroachDB 用 Range Sharding 把整個 key space 切成 range、每個 range 預設上限 ~512 MB、超過自動 split。每個 range 是一個獨立的 Raft group、有自己的 3 replica 分佈。

對比其他 distributed DB 的等價概念：

• DynamoDB partition：固定 hash 分區、自動 split 但 hot partition 容易撞 ceiling
• Spanner split：類似 range、但配置 / placement 語法不同
• Vitess keyspace：application 端決定 shard key、不透明 split

CockroachDB range 是 系統內建透明 的 — application 只看到 SQL table、不需要 shard key 設計。但 hot range 仍會發生（後面 failure mode 段展開）。

Leaseholder：每個 range 的 read / write entry point

每個 range 在任一時間點有一個 Leaseholder（通常等於 Raft leader）、承擔該 range 的所有 read / write coordination。leaseholder 也是 follower read 的 timestamp 邊界 holder。

leaseholder 概念對 production 訊號的影響：

• 寫入 latency 主要來自 leaseholder → follower replicas 的 Raft round trip
• leaseholder 集中在某節點 → 該節點 CPU 飽和（hot range 的根因之一）
• leaseholder 換手（lease transfer）短期 p99 spike — rebalance 期間 / 節點 graceful drain 都會觸發

操作流程：配置 + 驗證 + rollback 邊界

Cluster 起手配置

最小可運行配置是 3 節點（Raft quorum 下界）、production 通常 9 節點以上（3 region × 3 replica）。每個節點啟動時必須帶 locality tag、讓 Raft placement 知道副本怎麼分佈：

1cockroach start --insecure \
2  --locality=region=us-east1,zone=us-east1-a \
3  --max-offset=500ms \
4  --join=node1:26257,node2:26257,node3:26257

--max-offset 是 HLC 容忍上界、超過會 panic — 不要為了「避免 panic」加大這個值、會犧牲 linearizability 保證。

NTP / chronyd 是 必要前置、不是 nice-to-have。production 應該在每個節點配置：

• NTP server 至少 3 個獨立 source（避免單一 server drift）
• 監控 chronyc tracking 的 offset、超過 100ms 就應該 alert（遠在 500ms panic 邊界之前）

驗證點

 1-- 看每節點當前 clock offset 跟 cluster 其他節點
 2SELECT node_id, address, offset_min_nanos, offset_max_nanos
 3FROM crdb_internal.gossip_nodes;
 4
 5-- 看 Raft 健康（每個 range 的 leaseholder 跟 replica 分佈）
 6SELECT range_id, lease_holder, replicas
 7FROM crdb_internal.ranges
 8WHERE table_name = 'orders'
 9LIMIT 5;
10
11-- 看 cluster max-offset 設定
12SHOW CLUSTER SETTING server.clock.persist_upper_bound_interval;

Rollback 邊界

HLC + Raft 對 rollback 的態度跟 PostgreSQL 不同：

• HLC 時鐘前進不可回滾 — 不能「改一下 max-offset 後重啟試試看」
• Raft commit 不可回滾 — 一旦 majority ack、log entry 持久化
• 想還原業務狀態 只能新交易補償、不能 reverse Raft log

實務上的影響：incident 時不要嘗試「強制回到舊版本」、應該走 transaction-level rollback / compensation。對應 transaction boundary 卡 跟業務層補償設計。

失敗模式：clock skew / majority lost / hot range / retry storm

Clock skew panic

最常見：NTP 服務掛、節點時鐘漂移超過 max-offset、節點自動 panic。production incident 訊號：

• chronyc tracking 顯示 offset 持續成長
• CockroachDB log 出現 clock synchronization error
• Prometheus metric clock_offset_meannanos 接近 max-offset

修法：先恢復 NTP service、節點重啟前再次驗證時鐘已同步、不要動 --max-offset。對比 PostgreSQL primary 不關心 time skew、distributed SQL 把時鐘變成 first-class operational concern。

Raft majority lost

3 節點 cluster 失去 2 個、剩 1 個無法 commit、cluster 全 read-only（甚至連 read 都可能受影響、因為 leaseholder 拿不到 valid lease）。對比 PostgreSQL primary 失效後 streaming replica 仍可 read、CockroachDB 的 fault tolerance 是 quorum-based、不是 primary-replica。

production 規劃要點：跨 AZ / region 分佈時、必須保證任何 單一 failure domain 失敗後仍有 majority 存活。3 節點配 1 AZ → AZ 失敗 = cluster down。最小 production 配置是 3 AZ × 1 node 或 3 region × 3 node。

Hot range：leaseholder 節點 CPU 飽和

某個 range 寫流量集中（例：訂單 table primary key 是時間序 / 自增 ID）、leaseholder 節點變成熱點。徵兆：

• CockroachDB Console「Leaseholder count per node」分佈不均
• 某節點 CPU 飽和、其他節點閒置
• crdb_internal.ranges 顯示該 range 的 QPS 遠高於其他 range

修法：

• 手動 ALTER TABLE ... SPLIT AT VALUES (...) 強制 split hot range
• 改 primary key 設計、避免時間序 / 自增 ID（用 UUID / hash-prefixed key）
• partition by region、把 hot range 切到不同 region 的 leaseholder

Transaction retry storm

serializable contention 嚴重時 application 端 retry loop、CPU 雪崩。這個議題的 application contract 重塑屬獨立議題、見 transaction retry pattern。

Range split / rebalance 期間 p99 spike

自動 split 大 range、leaseholder 換手期間有 ~100ms 的 lease transfer 視窗、p99 短期 spike。production 訊號：CockroachDB Console「Rebalance queue size」非零 + p99 latency 同期波動。一般是良性 — rebalance 完就回穩。但連續波動代表 range 在「split → 寫熱 → 再 split」循環、要從 schema 層解。

容量與觀測：per-cluster 顆粒 + 來源分層

必看 metric

• Raft log queue size：Raft replication 延遲訊號、持續高代表 follower 跟不上
• Range count per node：range 分佈是否均勻、不均代表 placement 有偏
• Leaseholder count per node：leaseholder 分佈是否均勻、不均直接導致 CPU 熱點
• HLC offset distribution：時鐘同步健康
• Transaction retry rate：contention 訊號（細節在 transaction retry pattern）

Per-cluster 容量規劃顆粒（9.C40 Netflix 揭露、F4.7）

Netflix 的 380+ cluster 模型揭露一個反直覺結論：production scale 不是「全公司一條容量曲線」、而是 artery of small DBs。每個 cluster 對應一個 application boundary、cluster sizing 從幾個 node 到 60 nodes 不等、最大單區 60 nodes / 26.5 TB（case 觀察段表格揭露）。

容量規劃顆粒對齊 application boundary 的好處：

• 每個 cluster 各自規劃 capacity、不必預測「全公司加總 QPS」
• blast radius 限縮在單一 app — 某 cluster 撞 hot range / Raft majority lost、其他 cluster 不受影響
• upgrade / backup 可分批跑、不必整廠 maintenance window

但也帶來 ops 成本：380+ cluster 需要 專屬 Database Platform Team（含 backup、upgrade、incident response、capacity review）— Netflix case 直接揭露這個前置條件。沒這量級團隊就走 Cockroach Cloud managed、不要 self-host。

per-app cluster vs shared cluster 的決策軸主寫於 aurora-dsql-spanner-decision-tree、本篇 cross-link 不展開。

寫入 latency 預算（屬通用工程估算、case 未揭露具體數字）

以下數字屬通用工程估算 / 物理光速下界推導、DoorDash / Netflix / Hard Rock 三個 direct case 都沒揭露單一 cluster p99 latency。引用時必須明示來源層次：

• single-region 3-replica write p99 3-5ms（通用估算、跨 AZ Raft round trip）
• multi-region 跨洲 write p99 100-150ms（光速下界 — 跨洲 round trip 物理 ~70-80ms × 2）
• 單一 range 寫 throughput ~1000 QPS（通用估算、實際依 row size / contention 而定）
• 整 cluster scale-out 加 range、寫入吞吐近線性擴展（理論、實際依 hot range 分佈）

這些是「合理的工程估算量級」、不是 case 揭露的 p99 數字。讀者用這些做容量規劃時、應該 自己 benchmark 而不是直接套。

DoorDash 1.636 M QPS 引用紀律（F4.1、case 自帶警示）

DoorDash case 揭露的 1.636 M QPS 是 Aurora Postgres single-primary 在 2020-04-17 高峰撞牆的痛點（multi-hour outage）、不是 CockroachDB throughput claim。case 明確警告不要把這個數字當「CockroachDB 撐 1.636 M QPS 的證據」。case 沒揭露遷移後單一 CockroachDB cluster 的峰值、只說「跑更多 cluster、alert volume 反而下降」。

引用這個數字時的口徑：

• 寫成「Aurora 撞牆訊號」、不寫成「CockroachDB 容量證明」
• single-primary 撞牆的轉折點是 primary CPU + WAL flush rate（DoorDash 策略段 1）、不是 IOPS
• 「換引擎」前先評估「兩階段紓壓」— DoorDash 路徑是先把 hot table 拆到獨立 Aurora cluster（紓壓）、再規劃 Aurora → CockroachDB 換引擎（1.6 database migration playbook）

回路徑

• 9.5 瓶頸定位流程 判斷 Raft-bound vs storage-bound
• 9.6 容量規劃模型 replication factor × latency budget
• latency budget 卡 cross-region quorum 預算

邊界與整合

Sibling deep articles

• CockroachDB survival goals：Raft replica 怎麼分佈到 zone / region、決定 RTO / RPO
• CockroachDB transaction retry pattern：serializable default 對 application 契約的重塑
• CockroachDB locality-aware schema：range placement 控制 + locality 配置

跟 Aurora 對照

Aurora 是 storage-level quorum（4 of 6 storage replica）、compute 仍是 single primary。CockroachDB 是 range-level Raft（每個 range 獨立 majority）、compute 跟 storage 在每節點。兩者解的是不同 layer 的 consensus、結果是 Aurora 寫入仍受 primary 限制、CockroachDB 寫入隨節點線性擴。

Aurora DSQL / Spanner 對比

完整三家 distributed SQL 對比、撞牆訊號分型、PostgreSQL 相容性 audit、團隊規模 vs vendor sizing barrier 等議題在 aurora-dsql-spanner-decision-tree。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游選型
• 1.3 Transaction Boundary distributed transaction 邊界

何時不用本文

• single-region OLTP + 寫入未撞 PostgreSQL primary 天花板 → PostgreSQL 已足夠
• 對 cross-region quorum 100-150ms latency 預算無法接受 → 走 async replication 路線
• 沒 NTP 維運能力 → distributed SQL 把時鐘變 ops concern、沒準備好不要硬上

相關連結

• CockroachDB vendor overview
• 9.C39 DoorDash（Aurora 1.636 M QPS 撞牆訊號）
• 9.C40 Netflix（380+ cluster artery of small DBs）
• 9.C10 Spanner planetary scale（TrueTime 對照）
• distributed SQL 卡
• quorum 卡
• 官方：CockroachDB Architecture / Hybrid Logical Clocks paper / Raft paper

本文是 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 已足夠的訊號

本文是 CockroachDB vendor overview 的 implementation-layer deep article。Overview 已界定 CockroachDB 的 multi-region 能力、本文聚焦 survival goal 配置怎麼從業務 SLO 倒推、怎麼避開「cross-region = 更快」的動機誤判。Raft replica 分佈機制屬前置、見 HLC + Raft consensus。

Multi-region 上線前的兩個錯誤期待

multi-region CockroachDB cluster 上線時、團隊最常踩的兩個錯誤期待：

• 「default 配置應該就好、上線後再說」：default 是 SURVIVE ZONE FAILURE、一旦遇到 region failure 整 cluster 變 read-only、客訴湧入才發現要重新配
• 「跨 region 應該會讓全球用戶都更快」：跨 region quorum 物理上必然 增 寫入 latency、把 multi-region 動機誤判成 latency 優化會在 production 撞牆

讀者進來最常問：

• SURVIVE ZONE FAILURE 跟 SURVIVE REGION FAILURE 差在哪？
• 為什麼 region survival 寫入 latency 是 zone survival 的 3 倍？
• Default 配置是什麼、上線前該不該改？

要回答這三題、必須先把 survival goal 跟業務 SLO 的對應關係講清楚。

9.C41 Hard Rock Digital 提供最 concrete 的 SLO 倒推路徑：sportsbook 中 bet placement 不能 lose — 玩家下注後系統 crash 沒紀錄、對博彩牌照是合規事故。CockroachDB Raft 3-replica + 跨 AZ + survival goal 配置是把這個業務不可丟事件翻譯成 DB 層保證。

9.C40 Netflix 則提供反直覺判讀：60+ multi-region cluster 主要動機是 region failure 0 downtime、不是降 latency。Gaming cluster 48-node 跨 4 region 就是為了「region failover 不停服」、不是讓玩家延遲變低。

對照 9.C14 Standard Chartered 走另一條路：銀行受監管市場資料 不能跨境、不可用 region survival、必須拆每市場獨立 Aurora cluster + zone survival。這個 anti-recommendation 提醒「survival goal 不是越強越好、合規邊界優先於技術 HA 配置」。

核心機制：兩種 survival goal + replica placement

兩種宣告式配置

CockroachDB 把 HA 配置抽象成兩個 database-level（或 table-level）宣告：

• SURVIVE ZONE FAILURE（default）：失去 1 個 AZ 仍能寫入。replica 跨 AZ 分佈、但可能集中在同一個 region 內。對應 RTO ~ 數秒（Raft + Leaseholder 自動 failover）、RPO = 0（已 commit 資料不丟）
• SURVIVE REGION FAILURE：失去 1 個整個 region 仍能寫入。voting replica 強制跨 region、需要至少 3 個 region。對應 RTO ~ 數秒、RPO = 0、但寫入 latency 因跨 region quorum 結構性增加

survival goal 是 宣告式 配置 — application 端不用手動指定 Range Sharding 的 replica placement、Raft 根據 survival goal + locality 自動分佈、用 Hybrid Logical Clock 串接 commit ordering。對比通用 HA 設計（如 PostgreSQL streaming + Patroni manual failover）、CockroachDB 把這層邏輯壓進系統內。

Voting vs non-voting replica

region survival 模式下、CockroachDB 區分兩種 replica：

• Voting replica：參與 Raft majority 決策、commit 必須等 voting majority ack。region survival 下 voting replica 強制跨 region — 這就是 Cross-Region Quorum 拓樸、commit latency 受跨洲 RTT 物理硬限主導
• Non-voting replica：只用來 serve Follower Read、不參與 Raft commit。可以放在「不想列入 quorum 但希望本地 read 快」的 region

實務影響：region survival 下、跨 3 region 配置最少 3 voting replica（每 region 1 個）、寫入要等其中 2 個 region 的 ack。若想讓第 4 個 region 也能本地 read、可以加 non-voting replica、不影響 commit latency 但增加 storage cost。

配置語法

1-- Database-level
2ALTER DATABASE mydb SURVIVE REGION FAILURE;
3
4-- Table-level（覆蓋 database 設定）
5ALTER TABLE orders SURVIVE ZONE FAILURE;
6
7-- 驗證
8SHOW SURVIVAL GOAL FROM DATABASE mydb;
9SHOW ZONE CONFIGURATION FOR DATABASE mydb;

對應 quorum 卡、rto 卡、rpo 卡、blast radius 卡 的具體機制實現。

為什麼選 region survival 是業務動機判讀、不是技術 fact（F4.8）

Netflix 60+ multi-region cluster 揭露的反直覺結論：主要動機是 region failure 0 downtime、不是降 latency。跨 region quorum 物理上必然增 latency — 跨洲 round trip 物理 ~70-80ms、Raft majority 需要 2 個 region ack、寫入 p99 因此被光速下界限制。

Gaming cluster 48-node 跨 4 region 就是為了「region failover 不停服」、不是讓玩家延遲變低。Scope warning：case 沒揭露 Gaming cluster 具體 p99 數字、只揭露「48-node、跨 4 region、region failure 不停服」這個拓樸 fact 跟業務動機釐清。

引用時若提到「region survival 怎麼提升用戶體驗」、要 釐清成 survival、不是 latency 優化。讓讀者誤把跨 region 當成 latency 解法、是這條決策最常見的源頭錯誤。

操作流程：從業務 SLO 倒推 survival goal

配置前置

region survival 的最小可運行配置：

• cluster 至少 3 個 region
• 每 region 至少 3 個節點（保證單一 region 內也能扛 AZ failure）
• locality tag 配齊（region + zone）

1# Region us-east1 的節點
2cockroach start --locality=region=us-east1,zone=us-east1-a ...
3
4# Region us-west2 的節點
5cockroach start --locality=region=us-west2,zone=us-west2-a ...
6
7# Region eu-west1 的節點
8cockroach start --locality=region=eu-west1,zone=eu-west1-a ...

從業務 SLO 倒推（9.C41 Hard Rock 揭露、F4.11）

Hard Rock Digital sportsbook 揭露的 5 步倒推流程：

1. 列業務「不能丟」事件清單：bet placement、payment、order commit、settlement 等業務事件
2. 對每個事件決定 RPO：bet placement → RPO = 0（不可丟）、log audit → RPO = 1 分鐘（可接受 short-window 丟失）
3. 對 RPO = 0 事件決定故障域容忍：Hard Rock 案例 Outpost 或 AZ 失敗不丟 是業務要求、跨 region failure 不是 sportsbook 的硬需求（因為各州各自合規邊界）
4. 故障域容忍翻譯成 survival goal：
   • Outpost / AZ 失敗 → SURVIVE ZONE FAILURE 即可
   • region 失敗也不丟 → SURVIVE REGION FAILURE
5. 反過來驗 replica 分佈：survival goal 配置產出的 replica 分佈是否覆蓋業務故障域。Hard Rock CockroachDB Raft 3-replica + 跨 AZ → Outpost 失敗時其他 replica 在、自動 failover、滿足 bet placement RPO = 0

跟業務動機釐清的互補

Netflix 從技術配置 反推「為什麼選 region survival」（survival 動機、不是 latency）、Hard Rock 從業務不能丟事件 正推 該選哪個 survival goal。兩個方向是同一條路徑：

• 正推（Hard Rock）：業務不能丟 → RPO → 故障域 → survival goal
• 反推（Netflix）：survival goal 配置 → 揭露的不是「會變快」而是「region failover 不停服」

兩個方向互相驗證、避免把跨 region 配置誤解成 latency 工具。

升級流程跟 rollback 邊界

zone survival → region survival 是 非破壞性 配置變更、Raft 自動 rebalance replica。但要注意：

• rebalance 期間 cross-region traffic 暴增、p99 短期波動
• replication factor 增加 → storage 用量 × 新 RF
• 升級後 application 寫入 latency 結構性上升、要先在 staging 量過

監控 rebalance：

1-- 看 range 數量變化跟 rebalance queue
2SELECT range_count, used FROM crdb_internal.kv_store_status;
3
4-- CockroachDB Console「Rebalance queue size」應該歸零

Rollback：survival goal 可即時降級（region → zone）、replica 自動 rebalance、無不可逆動作。但 application 端如果已經依賴 region failover 0 downtime、降級回 zone survival 後 region failure 會讓 cluster 變 read-only — 配置 rollback 容易、業務 SLO rollback 不容易。

失敗模式：5 種典型錯配

Default zone survival 期待 region survival

最常見：上線後一個 region 掛、cluster 變 read-only、客訴。要在 production 前 明確選 survival goal、不依賴 default。

Region survival 但只配 2 region

Raft majority 需要 3 個獨立 fault domain。2 region 配置實際是 zone survival — 任一 region 失敗剩 1 region 拿不到 majority。要 region survival 至少 3 region。

Cross-region cost 暴漲

region survival 強制 voting replica 跨 region、每次 write 跨 region traffic × 3。AWS / GCP 的 cross-region data transfer 是高 markup、月費可能 2-3 倍。

production 前必須估：

• 寫 QPS × row size × 3 = cross-region traffic GB/day
• 對應 cloud provider 定價（AWS 跨 region $0.02/GB、GCP 類似量級）
• 月度 traffic cost 加總、跟 single-region 配置比

Locality 跟 survival goal 衝突

業務想把 user data partition by region 留 local（locality 配置）、但 survival goal 要求跨 region replica、結果 replica 仍跑遠端。這是 locality + survival 的互動議題、見 locality-aware schema 詳細展開。

合規邊界 violation

受監管市場（金融 / 醫療 / 博彩）資料 不能跨境、但 region survival 強制 voting replica 跨 region — 這直接違反合規。對照 9.C14 Standard Chartered 走的是「每市場獨立 Aurora cluster + zone survival」、不是 region survival。

合規邊界判讀：

• 跨境合規 禁止 跨 region replica → 不可用 region survival、走 cluster-per-市場
• 跨州合規 允許 跨州但要求資料留國內 → 可用 region survival、選同國內的 region
• 業務邏輯要求跨 boundary（如 Hard Rock 跨州統一帳戶）→ 不可拆獨立 cluster、必須 locality + placement

容量與觀測

必看 metric

• Raft replicas per node：replica 分佈均勻度
• Range count by survival mode：region survival 配置的 range 數量
• Cross-region write latency p99：跨 region quorum 實測 latency
• Rebalance queue size：rebalance 是否完成
• Network traffic by direction：cross-region 流量、cost signal

容量公式

• region survival 最小：region count × 3 nodes
• replica factor 預設 3、storage 用量 × replication factor
• cross-region traffic = write QPS × row size × (region count - 1)

Write latency 預算（屬通用工程估算、case 未揭露具體 latency 數字）

Scope warning：以下數字屬通用工程估算（跨 region 物理光速下界推導）、Netflix / Hard Rock case 都沒揭露 zone / region survival 的 p99 latency 數字。引用時必須明示來源層次：

• zone survival single-region 寫入 p99 5-10ms（跨 AZ Raft round trip）
• region survival 同洲跨 region p99 30-60ms（跨 region round trip × Raft majority）
• region survival 跨洲 p99 100-150ms（跨洲光速下界 ~70-80ms × 2）

數字屬「合理的工程估算量級」、不是 case 揭露的 p99。讀者用這些做容量規劃時應該自己 benchmark、不要直接套。

賽季型容量擺盪（9.C41 Hard Rock）

sportsbook 業務年度循環：NFL / NBA 季初季末流量結構性差異 — Hard Rock 100 nodes ↔ 33 nodes 擺盪是 計畫內、不是異常事件。CockroachDB 加減節點靠 range rebalance、不停服。

容量規劃要點：

• NFL / NBA / 國際賽事曆塞進預測模型、不要當 surprise
• scale up 提前 1-2 週執行、留 rebalance 時間
• scale down 在淡季低流量時段執行、避免 rebalance 期間 p99 spike

回路徑

• 9.6 容量規劃模型 survival goal 對 replica count / cost 影響
• 9.11 高峰事件準備 event-driven scaling
• latency budget 卡 cross-region 預算

邊界與整合

Sibling deep articles

• HLC + Raft consensus：Raft 機制是 survival goal 的基礎
• locality-aware schema：locality + survival 一起決定 placement
• transaction retry pattern：cross-region latency 加長 retry window

跟 Aurora 對照

• Aurora cross-AZ failover：zone-level survival 等價、但只在 single-region 內
• Aurora Global Database：跨 region async replication、不是 sync — region failure 仍會丟 last seconds
• CockroachDB region survival：sync majority、region failure RPO = 0

Aurora 沒有 row-level locality 配置、跨 region 強一致要走 Aurora DSQL（AWS 2024 GA）。

Aurora DSQL / Spanner 對比

完整三家 distributed SQL 在 multi-region survival 的取捨、見 aurora-dsql-spanner-decision-tree。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游
• 1.3 Transaction Boundary distributed transaction

何時不用 region survival

• single-region 已滿足業務 SLO → zone survival 即可
• 預算敏感、cross-region traffic cost 不划算
• 合規禁止跨境 → 必須拆每市場獨立 cluster + zone survival

相關連結

• CockroachDB vendor overview
• 9.C41 Hard Rock Digital（bet placement RPO=0 倒推）
• 9.C40 Netflix（Gaming 48-node 跨 4 region survival）
• 9.C14 Standard Chartered（anti-recommendation、為何 不用 region survival）
• quorum 卡 / rto 卡 / rpo 卡 / blast radius 卡
• 官方：CockroachDB Multi-Region Survival Goals / Multi-Region Capabilities Overview

本文是跨 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 看全圖

本文是 CockroachDB vendor overview 的 implementation-layer deep article。Overview 已界定 CockroachDB 的 PostgreSQL wire 相容定位、本文聚焦 serializable default 對 application transaction contract 的重塑。

Scope warning（最高、F4 Frame 2）：本篇整篇是跨 case 合成 frame、不是單一 case 揭露。3 個 CockroachDB direct case（9.C39 DoorDash / 9.C40 Netflix / 9.C41 Hard Rock Digital）對 application transaction retry contract 重塑的揭露 都偏弱 — DoorDash case 只寫 PostgreSQL wire protocol-level 相容、SQL 行為（serializable default / retry semantics / partial index）「仍要驗證」、沒直接寫 40001 serialization_failure / SAVEPOINT cockroach_restart / hot row contention / retry loop pattern。Netflix / Hard Rock case 完全沒寫 retry pattern。本章 retry pattern 議題從 Cockroach Labs 官方 SQL Layer docs + PG → CockroachDB 通用 contract 重塑視角合成、DoorDash 只作為 trigger context（撞牆訊號 + 觸發遷移）、不是 ground truth case study。讀者引用本章內容到實際系統前、應該 自己跑 application audit 而不是直接套合成的 pattern。

問題情境：從 PG READ COMMITTED 遷到 CockroachDB SERIALIZABLE 的 application 衝擊

團隊從 PostgreSQL（default READ COMMITTED）遷到 CockroachDB（default SERIALIZABLE）、上線後 application transaction retry 突然爆增、user-facing latency p99 高 5 倍、error rate 顯著上升。Driver 不會自動 retry — 應用層必須認得 40001 serialization_failure 並包 retry loop with exponential backoff。沒包就是直接拋例外給用戶。

讀者常問：

• 為什麼同樣的 transaction 在 CockroachDB 一直 retry、在 PostgreSQL 從來不會？
• 40001 serialization_failure error 怎麼處理、能不能直接 swallow？
• 我要把所有 application transaction 都改成 retry loop 包起來嗎？
• 能不能改 isolation level 回 READ COMMITTED、放棄 serializable 保證？

四題的回答都依賴一個前提：CockroachDB 的 application transaction contract 跟 PostgreSQL default 不一樣、必須重塑。

Scope warning explicit label：DoorDash case 沒揭露 retry pattern

DoorDash case 沒直接揭露 serializable retry contract / 40001 / SAVEPOINT pattern / hot row contention。case 只寫「PostgreSQL wire protocol 相容、實際 SQL 行為（serializable default、retry semantics、partial index）仍要驗證」（DoorDash 觀察段 / 策略段 3、F4.4）。

本章 retry pattern 議題是從 PG → CockroachDB 通用 contract 重塑視角合成、不是 DoorDash case 直接揭露。引用 DoorDash 時應該用：

• 正確口徑：「DoorDash 揭露 Aurora Postgres 1.636 M QPS 撞牆 → 引出 distributed SQL retry contract 需求、本章 retry pattern 議題是從 PostgreSQL → CockroachDB 通用 contract 重塑視角合成、不是 DoorDash case 直接揭露」
• 不要寫成：「DoorDash retry pattern」、「DoorDash 揭露 40001 處理」之類把合成包成 case fact 的語法

Case anchor（trigger context、不是 ground truth）

• 9.C39 DoorDash：提供「PG wire 相容、SQL 行為仍要 audit」的 case 警語（F4.4）、作為本章 為什麼 retry contract 要重塑 的觸發訊號。retry pattern 本體走 standard-driven（Cockroach Labs 官方 SQL Layer docs + Transaction Retry docs）

Sibling 對照 9.C4 DraftKings Aurora financial ledger 提供 PostgreSQL READ COMMITTED + Aurora 的另一條路徑 — 用 application-level sharding（200 個獨立 Aurora cluster）避開 retry、而不是處理 retry。Scope warning：DraftKings case 沒 寫 PostgreSQL READ COMMITTED retry pattern、case 是 Aurora 內 business sharding 路徑。本章引用 DraftKings 為「假想若把 DraftKings 遷 CockroachDB 會撞到 retry contract 重塑」合成對照、不是 case 直接揭露。

核心機制：serializable default 跟 PostgreSQL 的差異

來源分層：本段機制來源是 Cockroach Labs 官方 SQL Layer docs + Transaction Retry docs（standard-driven）、不是 從 case 抽取。3 個 direct case 都沒揭露這些機制細節。

Serializable 是 CockroachDB 的 default

CockroachDB 預設 SERIALIZABLE — 最強 isolation level、保證 transaction 結果等同某個 serial order（即所有 transaction 像逐個按順序執行）。對比：

Conflict detection：read / write set 衝突就 abort

CockroachDB 追蹤每個 transaction 的 read set 跟 write set。當兩個並行 transaction 的 read / write set 衝突、CockroachDB abort 後到的那個、發 Serialization Failure（40001 serialization_failure）。

對比 PostgreSQL serializable（SSI）：兩者都是「post-detect」、commit 時偵測 anomaly、不是 pre-lock。差別在 衝突偵測時機 跟 成本：

• PostgreSQL SSI：用 predicate lock 追蹤 query 條件、commit 時偵測
• CockroachDB：用 timestamp ordering + write intent、衝突 當下 就 abort

CockroachDB 的成本在「衝突立刻 abort 不等 commit」、好處是「retry window 較短、不會跑完整個 transaction 才發現衝突」。

Application 端 retry：driver 不自動處理

關鍵：CockroachDB driver 不自動 retry。application 收到 40001 serialization_failure 必須自己決定怎麼處理 — exponential backoff retry、circuit break、或拋給上層。

對比 PostgreSQL：PostgreSQL READ COMMITTED 幾乎不會丟 serialization failure（後 writer 等 lock 不 abort）、SERIALIZABLE 才會、但多數 application 沒走 SERIALIZABLE。CockroachDB 預設 就是 SERIALIZABLE、所以 retry loop 是 必要、不是 optional。

Savepoint pattern：官方推薦寫法

Cockroach Labs 官方推薦的 retry pattern 用 SAVEPOINT cockroach_restart：

 1BEGIN;
 2SAVEPOINT cockroach_restart;
 3
 4-- 做正常 transaction 工作
 5SELECT balance FROM accounts WHERE id = 1;
 6UPDATE accounts SET balance = balance - 100 WHERE id = 1;
 7UPDATE accounts SET balance = balance + 100 WHERE id = 2;
 8
 9RELEASE SAVEPOINT cockroach_restart;
10COMMIT;
11
12-- 如果中途 40001：
13-- ROLLBACK TO SAVEPOINT cockroach_restart;
14-- 重新跑 transaction body、再 RELEASE + COMMIT

cockroach_restart 是特殊保留 savepoint name — CockroachDB 認得這個名字、會把 ROLLBACK TO SAVEPOINT cockroach_restart 視為「重啟整個 transaction」而不是部分 rollback。

READ COMMITTED 是 v23.2+ 可選降級

CockroachDB v23.2+ 新增 READ COMMITTED isolation level — application 可選擇用 weaker isolation 換少 retry。但這是「降級」、失去 serializable 保證 — 對應的反例段在失敗模式段展開（金融 ledger 走 READ COMMITTED 可能讓 balance 變負）。

對應 isolation level 卡 跟 transaction boundary 卡。

DoorDash case 對接點（trigger context only）

DoorDash case 揭露 PG wire protocol-level 相容、明示 SQL 行為（serializable default / retry semantics / partial index）「仍要驗證」（F4.4）。本章機制段就是回答「audit 什麼」的具體展開 — 但 audit checklist 本體屬通用工程知識、case 沒 ground truth。

引用紀律：「DoorDash 揭露 PG wire 相容、SQL 行為仍要 audit、其中 serializable default 跟 retry semantics 是 application contract 重塑的核心議題」— 把 case 揭露的 fact 跟本章合成的 frame 分開講。

操作流程：retry loop 設計

Retry loop 偽碼

 1for attempt := 0; attempt < MAX_RETRIES; attempt++ {
 2    tx, err := db.Begin()
 3    if err != nil { return err }
 4
 5    _, err = tx.Exec("SAVEPOINT cockroach_restart")
 6    if err != nil { tx.Rollback(); return err }
 7
 8    // ... 跑 transaction body ...
 9
10    _, err = tx.Exec("RELEASE SAVEPOINT cockroach_restart")
11    if err == nil {
12        err = tx.Commit()
13        if err == nil { return nil } // 成功
14    }
15
16    if isSerializationFailure(err) { // SQLSTATE == "40001"
17        tx.Rollback()
18        backoff := time.Duration(math.Pow(2, float64(attempt))) * 10 * time.Millisecond
19        time.Sleep(backoff + jitter())
20        continue
21    }
22
23    tx.Rollback()
24    return err // 非 retry-able error
25}
26return ErrMaxRetriesExceeded

關鍵點：

• exponential backoff with jitter（避免 retry storm 同步）
• max retry 上限（避免無限 loop、要有 circuit breaker）
• 只 retry serialization failure、其他 error 直接拋
• transaction body 必須是 冪等 的（同樣 input 多次執行結果一致）

配置

1-- 改 transaction isolation level（v23.2+ 才支援 READ COMMITTED）
2SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
3
4-- 看當前 session 預設
5SHOW SESSION default_transaction_isolation;

驗證點

1-- 看 transaction retry 統計
2SELECT * FROM crdb_internal.txn_stats;
3
4-- 看哪些 query / table 衝突最多
5SELECT * FROM crdb_internal.cluster_contention_events ORDER BY count DESC LIMIT 10;

Idempotency 設計：transaction body 必須冪等

retry-safe transaction body 必須冪等 — 同樣 input 多次執行結果一致。這是 idempotency 在 distributed SQL retry contract 下的具體展開、不是 optional：

冪等性是 application 設計議題、不是 CockroachDB 配置可解的 — application contract 重塑的核心成本就在這。

Rollback 邊界

transaction 自身有 SAVEPOINT cockroach_restart 邊界、ROLLBACK TO SAVEPOINT 後可重試整個 transaction body。但：

• commit 後不可回滾 — 業務狀態還原只能新交易補償
• application 端如果在 transaction 外 cache state、retry 後 state 不一致（見失敗模式段）

失敗模式

Retry storm：contention 嚴重時 CPU 雪崩

當高頻寫入撞同一 row（例：全局 counter、熱門商品 inventory）、serializable 衝突率可能 100%、application 端 retry loop 不斷重跑、CPU 雪崩。

修法：

• Max retry 上限 + circuit breaker：超過就放棄、回 5xx 給 client、避免 retry storm 拖垮 cluster
• 改 schema 避開 hot row（partition by region、shard counter、用 sequence 代替全局 counter）
• 監控 crdb_internal.cluster_contention_events、針對 top-N table 改設計

非冪等 transaction 重試：double-count

最危險的 production bug：transaction body 不是冪等的、retry 後資料重複寫。ledger double-count、payment 重複扣款、log 重複記錄。

修法：

• transaction body 寫成 UPDATE balance SET balance = balance - X（相對運算）、不寫 UPDATE balance SET balance = Y（絕對賦值依賴 read 結果）
• INSERT 加 UNIQUE constraint + ON CONFLICT DO NOTHING
• 用 idempotency key（client 帶 UUID、server 端 dedupe）

Cross-statement state 假設

application 在 transaction 外 cache state（例：開 transaction 前 read 一個值、跑 transaction 期間用 cached 值）— retry 從 SAVEPOINT 重來時、cached state 不會重新讀、retry 後 state 不一致。

修法：

• 把 cached state 改成在 transaction 內 read
• retry loop 內 reset 所有 cached state
• 用 closure / scope 限制 cache 的生命週期到 transaction 內

Hot row contention

高頻 update 同一 row（例：全局計數器、熱門商品庫存、世界冠軍直播觀眾數）— serializable 衝突率接近 100%、無論 retry 多少次都繼續衝突。

修法（schema-level、不是 application-level）：

• 用 sequence 或 distributed counter（每節點本地 + 定期 aggregate）
• partition by hash key、把單一 row 拆成 N 個 sub-row
• 改 append-only + 定期 aggregate（事件流 + materialized view）

改 READ COMMITTED 後忘了驗證業務語意

v23.2+ 可改 READ COMMITTED、少 retry 但失去 serializable 保證。對金融 ledger：READ COMMITTED 可能讓 balance 變負（兩個並行 withdraw 都看到 balance=100、都扣 50、結果 balance=-50）。

修法：

• 金融 / 庫存 / 配額這類 strict consistency 場景必須留 SERIALIZABLE
• READ COMMITTED 只用在 容忍 stale read 的場景（搜尋結果 / 分析 dashboard）
• 改 isolation level 前 跑 application audit、確認業務語意能容忍

Long-running transaction：retry 機率隨時間線性上升

transaction read 開始時間早、commit 時 conflict window 大、retry 機率隨 transaction duration 線性上升。

修法：

• transaction scope 縮小 — 只包必要 read / write、不要把 RPC call / external API 放 transaction 內
• kill long-running query（SHOW SESSIONS + CANCEL QUERY）
• 把 batch update 拆成多個小 transaction、加 idempotency key

Distributed deadlock 跟 retry 互動

CockroachDB 用 distributed deadlock detection（每個 node 維護 wait-for graph、定期跨 node 交換）跟 PostgreSQL local lock 表的 deadlock detection 不同。一般情況下、被 detector 選為 victim 的 transaction 會直接 abort、application retry loop 應該收到 40001 後重跑。但在三種 corner case 下會跟 retry loop 形成雪崩 pattern：

• 多 transaction 同時撞同一組熱 row、deadlock detector 跨節點時間窗有 lag、多個 victim 同時 abort 後同時 retry、撞回同一個 deadlock window
• 跨節點的 distributed deadlock 偵測週期（預設 200ms+）放大 application retry latency、application 的 retry backoff 沒對齊偵測週期、形成「detect → abort → 快速 retry → 再 deadlock」迴圈
• Application 把 deadlock victim 當 40001 直接 retry、不分流出來看、就難以從 metric 區分「serialization conflict retry」跟「distributed deadlock retry」、調 schema / contention 的策略會用錯方向

修法（屬通用工程議題、case 未直接揭露）：

• Retry backoff 至少對齊 distributed deadlock 偵測週期、避免在偵測窗內快速 retry
• 加 jitter、不同 session 的 retry 不同步
• Application metric 分桶記錄 serialization_conflict_retry vs distributed_deadlock_retry、避免 contention 改善方向判錯
• Schema 設計階段避免「跨節點熱 row 環形依賴」（例：兩個服務交叉 update 對方的 counter row）

跨 case 合成 Scope warning：DraftKings 對照

DraftKings ledger 對照 — DraftKings case 沒寫 PostgreSQL READ COMMITTED retry pattern、case 內容是「Aurora 內 business sharding 路徑」、用 200 個獨立 cluster 解 Aurora single-primary 撞牆。本章把 DraftKings 拿來當「假想若遷 CockroachDB 需改 SERIALIZABLE + retry loop」的合成對照、不是 case 揭露的 fact。

實際 DraftKings 走 Aurora + application sharding 而非 CockroachDB、所以「DraftKings retry pattern」這個說法本身就是合成 — 應該寫成「DraftKings 走 Aurora sharding 避開 retry contract 重塑、若改走 CockroachDB 則需處理本章描述的 application 改寫」。

容量與觀測

必看 metric

• Transaction retry rate：per table、per session
• Serialization failure rate：絕對值 + ratio
• Transaction duration p99：long-running 是 retry 的根因之一
• Hot ranges by retry count：top contention 來源
• Application metric：retry count per request、retry-induced latency p99、circuit breaker trip count

容量公式

• 基底 QPS × (1 + avg retry count) = 實際 transaction load
• 例：1000 QPS、avg retry = 0.3 → 實際 cluster 處理 1300 transaction/s

retry rate 是 容量規劃必納入 的變數 — 沒算 retry 就會 underestimate 真實 load。

Tuning

• reduce transaction scope：transaction 越短、conflict window 越小
• kill long-running query：transaction 過長要主動截斷
• partition hot rows：schema-level 解 hot contention
• 改 isolation 到 READ COMMITTED（如果業務語意允許）

回路徑

• 9.5 瓶頸定位流程 判斷 retry-bound vs CPU-bound
• 9.6 容量規劃模型 retry rate × baseline QPS
• transaction boundary 卡
• isolation level 卡

邊界與整合

Sibling deep articles

• HLC + Raft consensus：為什麼 serializable 是 distributed SQL 的合理 default
• locality-aware schema：partition 降低 hot row contention
• survival goals：cross-region latency 加長 retry window

跟 PostgreSQL 對照

PostgreSQL READ COMMITTED 是 default、application 沒 retry loop 是 acceptable。遷 CockroachDB 必須 重塑 application transaction contract — 這是 migration 階段最容易 underestimate 的成本。

對應 PostgreSQL MVCC + SSI 機制細節、見 PostgreSQL MVCC + Lock Model。

Migration playbook

PG → CockroachDB 的 application audit 必看 transaction shape：

• 每個 transaction 的 read / write set 預估衝突率
• 是否冪等（retry-safe）
• transaction duration（long-running 是 retry 放大器）
• 業務語意能否容忍 READ COMMITTED（避開 retry 的 fallback）

1.x 章節互引

• 1.3 Transaction Boundary 上游 — distributed transaction 邊界
• isolation level 卡

何時不用本文

• 純 read-only workload、無 contention
• 已用 PostgreSQL serializable（application contract 相似、遷移衝擊小）
• 用 CockroachDB v23.2+ READ COMMITTED 且業務允許 stale read

相關連結

• CockroachDB vendor overview
• HLC + Raft consensus
• 9.C39 DoorDash（trigger context — PG wire 相容警語）
• 9.C4 DraftKings（合成對照 — Aurora sharding 路徑）
• PostgreSQL MVCC + Lock Model
• isolation level 卡 / transaction boundary 卡
• 官方：CockroachDB Transactions / Transaction Retry Error Reference / READ COMMITTED v23.2 announcement

本文是 CockroachDB vendor overview 的 implementation-layer deep article。Overview 已界定 CockroachDB 的 multi-region 能力、本文聚焦 locality 配置怎麼解合規地理邊界 + 跨 boundary 業務邏輯需求 — 用 Hard Rock Digital 跨 8 州單一邏輯 cluster 作為 concrete framing。Replica placement 機制屬前置、見 HLC + Raft consensus、survival goal 互動見 survival goals。

問題情境：Hard Rock 的跨州 sportsbook 拓樸創新

美國 sportsbook 受 Wire Act 規範、betting data 必須在下注州內處理 → 每個營運州都要有州內運算資源。傳統路徑是「每州一個獨立 silo、each silo 一個獨立 DB cluster」、合規上沒問題、但撞牆於三個業務需求：

• 跨州統一帳戶：玩家在 NJ 跟 FL 兩州都有帳戶、登入要看到統一 portfolio
• 跨州 reporting：總公司 BI / 財務 reporting 要橫跨所有州、不能 query N 個 cluster 後再合
• 跨州欺詐偵測：同一張身分證在不同州 IP 同時下注 → 風控引擎要看 cross-state aggregated 資料

9.C41 Hard Rock Digital 跨 8 州（AZ / IN / TN / FL / OH / IL / NJ / VA）用 AWS Outposts 把運算放進州內、但邏輯上仍是 一個 CockroachDB cluster — region placement 配置決定哪些 range 釘在哪個 Outpost / AWS region。case 觀察段直接揭露「跨所有 region 一個 logical database」這個拓樸 fact。

讀者常問：

• 合規逼我每州一 cluster、但跨州帳戶 / 風控 / 欺詐偵測撞牆怎麼辦？
• REGIONAL BY ROW 跟 REGIONAL BY TABLE 怎麼選、GLOBAL 又在什麼場景？
• GLOBAL table 為什麼讀快但寫慢、預設為什麼不全部用？
• AWS Outposts 是 latency 工具還是合規工具？

對照 9.C40 Netflix：60+ multi-region cluster、最大 Gaming cluster 48-node 跨 4 region、locality 配置直接影響 cluster 規模治理。

對照 9.C14 Standard Chartered Aurora 7 cluster fleet：銀行業跨國合規邊界、走的是「每市場獨立 Aurora cluster」路徑 — 跟 Hard Rock 邏輯一個 cluster 的拓樸完全不同。兩條路徑沒有對錯、trigger 條件不同（合規顆粒 × 跨 boundary 業務邏輯需求）。

核心機制：三種 table locality + row-level region 標記

三種 locality 模式

CockroachDB 用 Range Sharding 把 multi-region table 抽象成三種 locality、配合 Data Residency 合規邊界決定 row 落在哪個 region：

REGIONAL BY ROW：每 row 帶 crdb_region 隱含欄位

REGIONAL BY ROW 是 Hard Rock 場景的主要選擇。每 row 自動帶一個 crdb_region 隱含欄位、根據這個欄位把 row 對應的 range 釘在指定 region：

1ALTER DATABASE sportsbook PRIMARY REGION "us-east1-az";
2ALTER DATABASE sportsbook ADD REGION "us-east1-nj";
3ALTER DATABASE sportsbook ADD REGION "us-east1-fl";
4
5ALTER TABLE bets SET LOCALITY REGIONAL BY ROW;
6
7-- 寫入時指定 row 屬哪個 region
8INSERT INTO bets (id, user_id, amount, crdb_region)
9VALUES (..., ..., ..., 'us-east1-nj');

CockroachDB planner 自動感知 crdb_region、把 read / write 路由到 row 所在 region 的 leaseholder。application 不用手動配 shard key、不用 application 端路由邏輯 — 這是 distributed SQL 的「宣告式 locality」優勢。

GLOBAL：每 region local read、跨 region sync write

GLOBAL table 適合 reference data — 變更少、read 頻繁、需要全球 local read latency：

• read：每 region 都有 leaseholder、本地 read p99 跟 single-region 一樣
• write：跨 region quorum、p99 100ms+

實務上 GLOBAL 只放國家代碼、貨幣表、規則 lookup 等 變更頻率低 的 reference data。把 high-write workload 設成 GLOBAL 是典型錯配（見失敗模式段）。

Follower read：non-voting replica 提供本地 read

CockroachDB 區分 voting 跟 non-voting replica：

• voting replica 參與 Raft majority、決定 commit
• non-voting replica 不參與 commit、只 serve Follower Read

REGIONAL BY ROW + SURVIVE REGION FAILURE 配合時：row 所在 region 是 voting + Leaseholder、其他 region 有 voting replica（survival 需要）+ non-voting replica（本地 follower read）。

Follower read 讀到的是 closed timestamp 之前的資料 — strong consistency 場景不能用（read-after-write 會 stale）、但 dashboard / reporting / 風控分析等 容忍 stale 場景大幅降低 cross-region latency。

配置語法跟驗證

 1-- 設 database 的 region
 2ALTER DATABASE mydb PRIMARY REGION "us-east1";
 3ALTER DATABASE mydb ADD REGION "europe-west1";
 4
 5-- 設 table locality
 6ALTER TABLE users SET LOCALITY REGIONAL BY ROW;
 7ALTER TABLE country_codes SET LOCALITY GLOBAL;
 8ALTER TABLE orders_us SET LOCALITY REGIONAL BY TABLE IN "us-east1";
 9
10-- 驗證
11SHOW LOCALITY FROM TABLE users;
12SHOW RANGES FROM TABLE users;  -- 看 replica 分佈
13EXPLAIN ANALYZE SELECT * FROM users WHERE id = 1;  -- 看 query plan 是否 local

對應 stale read 卡、table partitioning 卡 的具體機制實現。

操作流程：從合規 boundary 到 schema 配置

配置 multi-region database

第一步是把所有 region 加入 database：

1-- 假設 cluster 已跨 8 個州（透過 AWS Outposts 在每州內）
2ALTER DATABASE sportsbook PRIMARY REGION "us-east1-virginia";
3ALTER DATABASE sportsbook ADD REGION "us-east1-nj";
4ALTER DATABASE sportsbook ADD REGION "us-east1-fl";
5ALTER DATABASE sportsbook ADD REGION "us-east1-az";
6-- ...其他州

每個「region」對應一個 Outpost / AWS region 的 locality tag、CockroachDB Raft 根據 locality 自動分佈 replica。

Table-level locality 配置

bet placement / settlement table 走 REGIONAL BY ROW（資料跟玩家所在州綁定）：

1ALTER TABLE bets SET LOCALITY REGIONAL BY ROW;
2ALTER TABLE settlements SET LOCALITY REGIONAL BY ROW;

account / user profile 跨州統一帳戶 — 玩家可能在多州下注、但 主檔 留 single region：

1ALTER TABLE accounts SET LOCALITY REGIONAL BY TABLE IN "us-east1-virginia";

reference data（運動類別、賽事 metadata）— 全球變更少、每州都要快速 read：

1ALTER TABLE sports_metadata SET LOCALITY GLOBAL;

Application 端寫入

1-- 顯式指定 row 所在 region（推薦、明確）
2INSERT INTO bets (id, user_id, state, amount, crdb_region)
3VALUES (..., ..., 'NJ', 100.00, 'us-east1-nj');
4
5-- 或用 gateway_region() default（依 application 連到的 region）
6INSERT INTO bets (id, user_id, state, amount)
7VALUES (..., ..., 'NJ', 100.00);  -- crdb_region 自動填 gateway 端

gateway_region() 是便利但有風險的 default — 如果 application server 在 us-east1-fl 但 user 在 NJ 下注、row 會被放到 FL 而不是 NJ、違反 Wire Act 合規。Hard Rock 場景下顯式指定 crdb_region 是更安全的做法。

Rollback 邊界

locality 變更即時生效、Raft 自動 rebalance — 無不可逆動作。但 rebalance 期間 cross-region traffic 暴增、p99 短期 spike。production 環境改 locality 應該選低流量時段、並監控 rebalance queue。

失敗模式

「拆獨立 cluster 解合規但破壞業務邏輯」反模式（Hard Rock 對比 Standard Chartered、F4.10）

直覺路徑是「合規要求資料留某地理邊界 → 每邊界開一個獨立 cluster」、合規上沒問題。但獨立 cluster 之間：

• 玩家統一帳戶撞牆 — 每 cluster 各自有 user table、跨 cluster query 麻煩
• 跨州 reporting 要 N 個 cluster + ETL pipeline
• 欺詐偵測要 cross-state aggregated view — 獨立 cluster 拼不出

Hard Rock 選擇 邏輯一個 cluster + 物理跨州 Outpost placement — 合規 boundary 用 region placement 表達、不是 cluster fragmentation。對比 Standard Chartered：

• Standard Chartered Aurora 7 cluster fleet：銀行業跨國合規邊界、跨 cluster 業務邏輯需求弱（每市場用戶獨立、跨境統一帳戶不是核心 driver）→ 用 fleet 拓樸吸收合規可行
• Hard Rock Wire Act 跨州：跨州統一帳戶 + 跨州 reporting + 欺詐偵測是 核心業務需求 → 必須邏輯一個 cluster、用 locality + placement 吸收合規

兩條路徑沒有對錯、trigger 條件不同。判讀軸線：

• 合規顆粒（跨國 vs 跨州 vs 跨 AZ）
• 跨 boundary 業務邏輯需求強度（強 → CockroachDB locality / 弱 → 拆獨立 cluster 可行）
• 團隊運維能力（CockroachDB 邏輯一個 cluster vs Aurora 多 cluster fleet 的人月成本）

「Outposts 是 latency 工具」動機誤判（F4.13、case 反直覺判讀）

AWS Outposts 主要為「資料留某地理邊界」存在、latency 改善是 副作用。Hard Rock 策略段 2 明確警告：「決策時先看合規驅動力、latency 改善列為 bonus」。

若把 Outposts 當跨州 latency 改善工具、會在沒合規驅動的場景過度投資 — Outposts 硬體成本 + 維運複雜度遠高於純 AWS region 部署。實務判讀：

• 有合規驅動（Wire Act / GDPR / 各州博彩牌照）→ Outposts 是合理投資
• 純 latency 優化 → 用 AWS Local Zones、用 CDN、用 edge cache、不要碰 Outposts
• 兩者並存 → Outposts 投資按 合規 計算、latency 改善是 ROI 加分項

GLOBAL table write 太慢

GLOBAL table 每次 write 跨 region quorum、p99 100ms+。用在 high-write workload 是典型錯配 — 該用在 reference data（國家代碼、貨幣表、規則 lookup）。

判讀：

• write QPS < 10 + read QPS 跨 region 高 → GLOBAL 合理
• write QPS > 100 → 不要用 GLOBAL、改 REGIONAL BY ROW + 接受 cross-region read 偶爾走 follower

REGIONAL BY ROW 但 row 沒設 crdb_region

application 寫入時忘了設 crdb_region、default 走 gateway_region() — application server 所在 region 變成 row 的 region。常見後果：

• application server 集中部署 → 所有 row 跑同一 region、locality 失效
• application server 跟 user 不同 region → 合規 violation（Wire Act 場景）

修法：顯式指定 crdb_region、把 user 的合規區域當業務欄位明確管理。

Cross-region join 跑爆 latency

兩個 REGIONAL BY ROW table join、planner 要跨 region 拉資料、p99 暴漲。

修法：

• 兩個 table partition by 同樣 的 key（如：user_id）、保證 join 對應 row 在同 region
• 不能保證 co-location 時、考慮用 follower read 接受 stale 資料
• query 重寫成多步：先在各 region 算 local 結果、application 端 merge

Follower read 假設 strong consistency

non-voting replica 是 closed timestamp 之前的資料、read-after-write 場景仍會 stale。

修法：

• read-after-write critical（如：剛下注立刻顯示「下注成功」）→ 不能走 follower、要走 leaseholder
• dashboard / 分析 / reporting 容忍 stale → follower read 安全、大幅降 latency

Data residency 違規

受監管州 / 國資料應留 boundary 內、但 application 從別 region 寫入 row、沒設 crdb_region、資料跑出 boundary、合規 violation（Wire Act / GDPR / 各州博彩牌照都有類似條款）。

修法（schema-level + application-level 雙保險）：

• schema：REGIONAL BY ROW + crdb_region 是 NOT NULL + CHECK constraint 限制可選值
• application：寫入前明確驗證 crdb_region 對應 user 所在合規區
• 監控：定期跑 SELECT crdb_region, count(*) FROM bets GROUP BY crdb_region 確認分佈符合預期

Hard Rock 場景的組合配置（9.C41）

bet placement / settlement / account management 都需要跨州資料存取 + 州內合規 placement。Hard Rock 案例揭露的具體組合：

• REGIONAL BY ROW + crdb_region 標州別 + region placement pin Outpost
• account 跨州統一 → REGIONAL BY TABLE IN primary region、其他州走 follower read
• sports metadata → GLOBAL、reference data 全州 local read

這是滿足 Wire Act + 跨州業務邏輯的組合、不是唯一解、但揭露了 schema 設計的 判讀軸 — 不是「locality 越強越好」、是「locality 對應業務 + 合規邊界」。

容量與觀測

必看 metric

• Range locality distribution：range 分佈跟 locality 配置是否一致
• Cross-region query count：cross-region query 數量、locality 失效訊號
• Follower read rate：follower read 命中率、降 latency 效果
• Leaseholder distribution by region：leaseholder 在 region 間是否均勻

容量公式

• cross-region traffic = GLOBAL table write QPS × region count
• REGIONAL BY ROW 跨 region read = follower read rate × QPS
• storage 用量 = base storage × replication factor × (voting + non-voting replica count)

容量上限

• region count：建議 ≤ 5（多 region 增加 quorum latency + 維運複雜度）
• GLOBAL table 數量：建議只放 reference data、總 row 數 < 10 萬
• single range 寫 throughput ~1000 QPS（通用估算、見 HLC + Raft consensus）

回路徑

• 9.5 瓶頸定位流程 判斷 cross-region-bound vs CPU-bound
• 1.11 全球分散式 OLTP 上游合規 / latency 取捨

邊界與整合

Sibling deep articles

• survival goals：locality + survival goal 一起決定 replica placement
• transaction retry pattern：partition 降低 hot row contention 的 schema 路徑
• HLC + Raft consensus：leaseholder 跟 locality 的關係

跟 Aurora Global Database 對照

Aurora 不支援 row-level locality — 跨 region 只能 cluster-per-region + async replication。CockroachDB 在一個 cluster 內可以 fine-grained locality、application 不需要管 cross-cluster 路由。Aurora Global Database 適合 async DR 場景、不適合 跨 region 強一致 + row-level locality 需求。

跟 Spanner interleaved tables 對照

Spanner 的 Interleaved Table 跟 CockroachDB 的 REGIONAL BY ROW 概念類似（parent-child row co-location）、語法不同。Spanner 在 GCP region 內 placement、無 Outposts 等效 — Hard Rock 場景下 Spanner 不能直接套用。

Aurora DSQL / Spanner 對比

完整三家 distributed SQL 在 locality / multi-region placement 的取捨、見 aurora-dsql-spanner-decision-tree。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游
• stale read 卡
• table partitioning 卡

何時不用本文

• single-region 部署、無 data residency 需求 → 用 default locality 即可
• 合規邊界 禁止 跨境 replica（如 Standard Chartered 模式）→ 拆 cluster-per-市場、不走本文 locality 路徑
• 純 latency 優化、無合規驅動 → 用 CDN / cache / Local Zones、不必動 schema

相關連結

• CockroachDB vendor overview
• 9.C41 Hard Rock Digital（concrete framing — 跨 8 州 + Outposts + 邏輯一個 cluster）
• 9.C40 Netflix（多 region locality 規模治理）
• 9.C14 Standard Chartered（fleet 拓樸對照、不同合規邊界）
• stale read 卡 / table partitioning 卡
• 官方：CockroachDB Multi-Region Capabilities / Table Localities / Follower Reads

本文是 CockroachDB vendor overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。本文聚焦 三種 table locality 怎麼選、選錯的 latency / 一致性後果與重配代價。Schema 怎麼配合 locality 設計（合規 boundary、跨州業務邏輯、Outposts 拓樸）主寫於 locality-aware schema、survival goal 的存活機制主寫於 survival goals、本文兩者都 cross-link、不重複展開。

問題情境：multi-region cluster 起來了、每張 table 該設哪種 locality

團隊把 CockroachDB 跨 region 拉起來、ALTER DATABASE ... ADD REGION 也跑完了，接下來面對的是逐張 table 的 locality 決策。這個決策的成本結構很不對稱：設對了，read / write 走本地 leaseholder、latency 貼著單區水準；設錯了，每次寫入或讀取都吃一趟跨 region round trip，p99 從個位數毫秒跳到上百毫秒。

multi-region table locality 是 把「資料的地理歸屬」跟「讀寫路徑」綁在一起 的宣告。CockroachDB 提供三種 locality，對應三種「資料屬於誰、誰要快」的業務形狀：

• REGIONAL BY TABLE：整張 table 歸屬單一 region，該 region 讀寫快、其他 region 慢。
• REGIONAL BY ROW：每一 row 各自歸屬一個 region，row 所在 region 讀寫快。
• GLOBAL：資料屬於所有 region，每個 region 本地讀都快，但寫入要跨 region 達成共識。

讀者進來最常卡的三題：

• 三種 locality 對應什麼業務形狀、判讀軸是什麼？
• GLOBAL 既然每區讀都快，為什麼不全部設 GLOBAL？
• 上線後發現 locality 設錯，重配的代價有多高、能不能無痛改？

這三題都是 把業務的資料歸屬與讀寫熱點，翻譯成副本拓樸 的設計決策，語法層面反而簡單。

問題情境最常見的 trigger：9.C40 Netflix 的 60+ multi-region cluster、最大 Gaming cluster 48-node 跨 4 region。case 揭露一個反直覺判讀 — multi-region 的主要動機是 region failure 0 downtime、不是降 latency；跨 region quorum 物理上會 增 寫入 latency。這條判讀直接決定 table locality 怎麼設：當 multi-region 的目的是 survival 而非 latency，把高寫入 table 設成 GLOBAL（跨區同步寫）就是把成本花在錯的地方。

9.C41 Hard Rock Digital 則提供 row-level 歸屬的 concrete framing：跨 8 州 sportsbook、bet 資料按下注州歸屬、邏輯上仍是一個 cluster。case 觀察段揭露「跨所有 region 一個 logical database」這個拓樸 fact — 也就是 row-level locality 撐起了「合規分州 placement + 單一邏輯 DB」的組合。Hard Rock 的合規驅動與 schema 設計細節在 locality-aware schema 展開，本文只取「row-level 歸屬」這個 locality 選擇本身。

核心機制：三種 locality 的判讀軸 + survival goal 互動

三種 table locality 的差異，本質是 leaseholder（讀寫入口）跟資料歸屬 region 之間的關係。leaseholder 機制屬前置、見 HLC + Raft consensus；本文聚焦三種 locality 把 leaseholder 放在哪、因此誰快誰慢。

判讀軸：資料歸屬的顆粒 × 讀寫熱點分佈

選 locality 的第一個判讀軸是 資料歸屬的顆粒：整張 table 屬於一個 region（table 級），還是每 row 各屬一個 region（row 級），還是屬於所有 region（global）。第二個判讀軸是 讀寫熱點落在哪：本地讀為主、本地寫為主、還是全球讀為主。

每一格的判讀都要回到該情境，不能只看表。

REGIONAL BY TABLE 適合 整張表的讀寫熱點集中在單一 region 的情況。例如一張只服務日本市場的訂單表，把整張表的 leaseholder 釘在 asia-northeast1，日本端的應用讀寫都走本地 leaseholder，跨區應用偶爾讀則走 follower read 接受 stale。判讀訊號：這張表的寫入請求是否 95% 以上來自同一 region。如果不是，table 級歸屬會讓多數寫入吃跨區延遲。

REGIONAL BY ROW 適合 每一 row 跟某個地理位置強綁定、但整張表跨多 region 的情況。玩家帳戶、訂單、下注紀錄都屬於這類 — 每筆資料屬於某個用戶所在 region，但整張表服務所有 region 的用戶。row 透過隱含的 crdb_region 欄位決定歸屬，leaseholder 跟著 row 走。判讀訊號：同一張表的不同 row，讀寫熱點是否分散在不同 region。是的話，row 級歸屬讓每個 row 都貼著自己的用戶。

GLOBAL 適合 讀遠多於寫、且每個 region 都要本地快讀 的 reference data。國家代碼、貨幣表、運動賽事 metadata 這類資料變更稀少、但每個 region 的每次查詢都要用到。GLOBAL 讓每個 region 都能本地讀（讀到 closed timestamp 前的一致快照），代價是寫入要跨 region 達成共識。判讀訊號：寫入頻率是否低到「跨區寫的慢可以忽略」。

為什麼不全部設 GLOBAL

GLOBAL 的「每區讀都快」看似適合全表套用，但它對 寫入 收取跨 region quorum 的全額成本。GLOBAL table 的讀之所以能本地完成，是因為 CockroachDB 維護一個全球同步的 closed timestamp，讓每個 region 都能安全地本地讀稍早的快照；維護這個 timestamp 的代價是每次寫入都要跟所有 region 協調。

Scope warning：GLOBAL table 的跨 region 寫入 p99、REGIONAL BY ROW 的本地寫入 p99、closed timestamp 的傳播間隔等具體數字，屬 vendor 規格與部署拓樸（region 距離、replica 數）的函數，三個 anchor case（DoorDash / Netflix / Hard Rock）都未揭露單一 table 的 latency 數字。本文只給量級判讀（本地 quorum vs 跨洲 quorum 差一到兩個數量級），具體值需 benchmark 自身拓樸並 cross-verify CockroachDB Table Localities 文件。

因此「全部設 GLOBAL」會把所有寫入推上跨 region 路徑，等於放棄了 distributed SQL 把寫入分散到各 region 的核心優勢。GLOBAL 的正確用法是限定在 變更頻率低、全球都要快讀 的 reference data。

Survival goal 怎麼跟 locality 一起決定副本拓樸

table locality 決定 leaseholder 放哪、讀寫走哪條路徑；survival goal 決定 副本要分佈到幾個 failure domain 才能在故障後存活。兩者一起決定每張 table 的副本拓樸。

survival goal 的存活機制本身（SURVIVE ZONE FAILURE vs SURVIVE REGION FAILURE、怎麼從業務 SLO 倒推、RTO / RPO 怎麼算）是 survival goals 的 SSoT，本文不重複展開。本文只取兩者 互動 的一個關鍵後果：把 SURVIVE REGION FAILURE 套到 REGIONAL BY ROW table 時，每個 region 的 row 不只需要本地 voting replica，還需要在 其他 region 放足夠的 voting replica 才能在整個 region 失效後仍達成 quorum。這會把跨 region 的 voting replica 數量推高，間接增加寫入要協調的範圍。

判讀路線：先依業務的資料歸屬與讀寫熱點選 locality（本文），再依業務的 region failure 容忍度選 survival goal（survival goals），兩者疊加後才得到最終副本拓樸與 latency 結構。

操作流程：配置、驗證、每步檢查生效

第一步：確認 database 已加入所有 region

table locality 的前提是 database 已宣告 region。先確認 region 列表正確，再設 table locality。

1-- 看 database 已有哪些 region、哪個是 primary
2SHOW REGIONS FROM DATABASE mydb;

驗證點：輸出的 region 數量與名稱要對齊實際部署的 region。少一個 region，後面把 table 設成該 region 的 REGIONAL BY TABLE 會直接報錯。

第二步：依判讀軸設定每張 table 的 locality

1-- 整張表服務單一市場
2ALTER TABLE orders_jp SET LOCALITY REGIONAL BY TABLE IN "asia-northeast1";
3
4-- 資料跟用戶地理綁定
5ALTER TABLE accounts SET LOCALITY REGIONAL BY ROW;
6
7-- 低寫入、全球本地讀的 reference data
8ALTER TABLE currency_codes SET LOCALITY GLOBAL;

驗證點：

1-- 確認每張 table 的 locality 設定符合預期
2SHOW CREATE TABLE accounts;   -- locality 子句會出現在輸出尾段

第三步：驗證讀寫路徑真的走本地

設了 locality 不代表查詢真的走本地路徑 — 寫入時 row 的 crdb_region 沒設對、或 query 沒帶上對應條件，仍會跨區。用 EXPLAIN ANALYZE 看實際 plan。

1-- 看 query 是否在 row 歸屬 region 本地完成、有沒有跨 region 拉資料
2EXPLAIN ANALYZE SELECT * FROM accounts WHERE id = $1;

驗證點：plan 中不應出現大量跨 region 的 distributed scan；REGIONAL BY ROW 的點查應落在 row 歸屬 region 的單一 leaseholder。

第四步：驗證副本分佈符合 locality + survival goal

1-- 看每張 table 的 range 副本實際分佈在哪些 region
2SHOW RANGES FROM TABLE accounts;

驗證點：副本分佈要同時滿足 locality（leaseholder 在歸屬 region）跟 survival goal（跨足夠 failure domain）。兩者衝突時，CockroachDB 以 survival goal 為硬約束調整副本數，這會反過來影響 latency — 對應 survival goals 的 latency 暴漲失敗模式。

失敗模式：locality 選錯的高代價回退

GLOBAL 套到高寫入 table

把高寫入 table（訂單、下注、status 變更）設成 GLOBAL，每筆寫入都跨 region 共識，寫入 p99 結構性暴漲、寫入吞吐被跨區協調卡死。徵兆：CockroachDB Console 的跨 region network traffic 隨寫入量線性成長、寫入 p99 跟 region 距離正相關。

修法：把 table 改成 REGIONAL BY ROW（按用戶歸屬）或 REGIONAL BY TABLE（按市場歸屬）。

Anti-recommendation：reference data 之外的任何 table，預設都不要設 GLOBAL。GLOBAL 的判準是「寫入頻率低到跨區寫的慢可以忽略」，高寫入 workload 直接排除。

REGIONAL BY ROW 但 row 沒帶正確 crdb_region

REGIONAL BY ROW 靠 crdb_region 決定 row 歸屬。寫入時沒顯式指定，default 走 gateway_region() — application server 所在 region 變成 row 歸屬。後果是 row 被釘在 application server 那一區，而非用戶所在區，locality 形同失效（甚至在合規場景違反 data residency，見 locality-aware schema）。

修法：寫入時顯式指定 crdb_region 為用戶所在 region，並用 NOT NULL + CHECK constraint 把可選值鎖死。

選錯 locality 的重配代價（高代價不可逆情境的回退敘事）

table locality 選錯，重配本身語法上一行就能改（ALTER TABLE ... SET LOCALITY ...），但 資料層面的重配代價高且有持續影響，需要專屬回退計畫，不能比照「改個 config 重啟」對待。

重配 locality 會觸發 CockroachDB 把受影響 range 的副本搬到新拓樸對應的位置。把一張大 table 從 GLOBAL 改成 REGIONAL BY ROW，或從 single region 改成 row-level 跨多 region，意味著大量 range 要 rebalance — 期間跨 region network 流量暴增、leaseholder 反覆換手、p99 持續波動，table 越大、region 越多，rebalance 窗口越長。這是隨資料量延長的背景過程，遠非秒級操作。

更關鍵的是 REGIONAL BY ROW 的 crdb_region 是 資料內容，不只是 metadata。如果原本 row 的歸屬區設錯（例如全部落到 application server 那一區），重配 locality 不會自動把 row 搬到正確的用戶 region — 還要 回填 crdb_region 欄位，這是一次 data migration，不是 schema 變更。合規場景下，錯誤歸屬期間寫入的資料可能已經違反 data residency，回退時要連同合規證據一起盤點。

回退計畫的要素：

• 重配前估算受影響 range 數量與資料量，換算 rebalance 窗口，選低流量時段執行。
• 重配 REGIONAL BY ROW 時，分開處理「locality 宣告變更」與「crdb_region 回填」兩個動作，回填走分批 update 並監控 contention。
• 重配期間監控 rebalance queue 與跨 region traffic，設好「波動超過閾值就暫停 rebalance」的 tripwire。
• 合規場景下，先盤點錯誤歸屬期間的資料是否已違規，再決定回填策略與是否需要合規通報。

Anti-recommendation：不要在 production 高峰時段直接對大 table 改 locality 試效果。locality 是「上線前依業務形狀想清楚再設」的決策，不是「線上 A/B 試」的旋鈕。

Cross-region join 跑爆 latency

兩張 REGIONAL BY ROW table join，若 join key 不保證兩邊 row 在同 region，planner 要跨 region 拉資料，p99 暴漲。

修法：兩張 table 用同一個歸屬 key（如 user_id），讓 join 對應的 row co-locate 在同 region；無法 co-locate 時，對容忍 stale 的查詢改走 follower read。

容量與觀測

必看 metric

• Cross-region query count：locality 是否生效的直接訊號，數值高代表查詢在跨區拉資料。
• Leaseholder distribution by region：leaseholder 是否落在資料歸屬 region，不均代表 locality 配置或 crdb_region 有偏。
• Rebalance queue size：locality 重配 / 副本搬遷期間的進度訊號，持續非零代表 rebalance 未收斂。
• Cross-region network bytes：GLOBAL table 寫入與 cross-region join 的成本訊號。

容量判讀

• GLOBAL table 的跨區寫入成本 ≈ 寫入 QPS × region 數，region 越多成本越高，所以 GLOBAL 只放低寫入 reference data。
• REGIONAL BY ROW 的跨區讀成本 ≈ 落到非歸屬 region 的讀 QPS，這部分若高，代表 crdb_region 歸屬與實際讀熱點不一致。
• region 數量建議維持精簡 — 每多一個 region，跨區協調與重配窗口都變長。

Scope warning：region 數量上限建議、單 range 寫入吞吐量級、closed timestamp 傳播間隔等為 vendor 通用估算，非 case 揭露數字，容量規劃前以 CockroachDB Multi-Region 文件 cross-verify 並 benchmark 自身拓樸。

回路徑

• 9.5 瓶頸定位流程 判斷 cross-region-bound vs CPU-bound。
• 9.6 容量規劃模型 region count × replica × latency budget。
• latency budget 卡 跨 region quorum 預算。

邊界與整合

Sibling deep articles

• locality-aware schema：schema 怎麼配合 locality 設計 — 合規 boundary、跨州業務邏輯、Outposts 拓樸、crdb_region 作為合規欄位的管理。本文是「三種 locality 怎麼選」、該文是「選好後 schema 怎麼配合」，兩者互補不重複。
• survival goals：survival goal 的存活機制與 SLO 倒推 — 本文只取「survival goal 與 locality 互動如何影響副本拓樸」這一個交點，存活機制本身以該文為 SSoT。
• HLC + Raft consensus：leaseholder 與 range 機制 — locality 決定 leaseholder 放哪，前置機制在該文。

跟 Spanner / Aurora 對照

Spanner 在 GCP region 內做 placement，無 AWS Outposts 等效；Aurora 不支援 row-level locality，跨 region 只能 cluster-per-region + async replication。完整三家 distributed SQL 在 multi-region placement 的選型對比，是 aurora-dsql-spanner-decision-tree 的 SSoT，本文不重展三方對比。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游 latency / 一致性取捨。
• stale read 卡、follower read 卡 — GLOBAL 與跨區讀的一致性語意。

何時不用本文

• single-region 部署：用 default locality 即可，三種 locality 在單區無差異。
• 從 PostgreSQL 遷到 CockroachDB 的整體流程：見 PostgreSQL → CockroachDB migration，本文只處理遷移後的 table locality 配置。

相關連結

• CockroachDB vendor overview
• 9.C40 Netflix（multi-region 動機是 survival 非 latency）
• 9.C41 Hard Rock Digital（row-level 歸屬 + 單一邏輯 cluster）
• distributed SQL 卡
• 官方：CockroachDB Table Localities / Multi-Region Overview / Follower Reads

本文是 CockroachDB vendor overview 的 implementation-layer deep article。寫作參照 vendor deep article methodology。本文聚焦 Cockroach Cloud serverless 與 dedicated 的取捨判讀、RU 計費結構、冷啟動 / scale 行為、何時用 serverless。Self-managed 規模化的運維責任（Netflix Platform Team 養 380+ cluster）跟賽季型擴縮（Hard Rock 100 ↔ 33 node）作為 對照軸 引用、不重展 self-host 運維細節。

問題情境：要 managed CockroachDB、但 serverless 跟 dedicated 該選哪個

團隊決定不自管 Raft / backup / upgrade，改走 Cockroach Cloud managed，接著面對的是 serverless 跟 dedicated 兩種 managed 形態的取捨。這個取捨不是「哪個比較好」，而是 容量壓力的形狀對應哪種計費與 scale 模型。

Cockroach Cloud serverless 是 把容量決策從「預先 provision 節點」換成「按實際用量計費 + 自動 scale」 的 managed 形態。它消去了 cluster sizing 這個決策 — 沒有「要開幾個 node」的問題，資源隨 workload 自動伸縮，甚至閒置時 scale 到接近零。代價是計費單位變成抽象的 Request Unit（RU），用量暴衝時成本跟著暴衝，且共享底層資源帶來冷啟動與性能可預測性的取捨。

dedicated 則保留 固定的 cluster 容量 + 可預測的計費，由 vendor 代管運維但容量仍是團隊決策。

讀者進來最常卡的三題：

• serverless 的 RU 計費到底計什麼、怎麼估自己的 workload 會花多少？
• serverless 閒置會 scale 到零，那冷啟動會不會讓第一個請求變慢？
• 什麼 workload 適合 serverless、什麼時候該選 dedicated 或乾脆 self-managed？

這三題的共同核心是 把 workload 的流量形狀（穩定 vs 突發、可預測 vs 不可預測、高峰 vs 長尾）翻譯成計費與 scale 模型。

問題情境的對照 trigger 來自兩個 self-managed 規模的 case，它們界定了「什麼時候 serverless / dedicated 都不對、要 self-host」的邊界。

9.C40 Netflix 是 self-managed 380+ cluster（case 揭露 380+ 為含非 production 的總數、production cluster 160+），case 明確揭露這需要 專屬 Database Platform Team（backup、upgrade、incident response、capacity review），並警示「沒這量級團隊就走 Cockroach Cloud managed、不要 self-host」。這條判讀的反向就是本文的入口 — 大多數團隊沒有 Platform Team，managed 才是合理起點，問題只剩 serverless 還是 dedicated。

9.C41 Hard Rock Digital 是 self-managed、賽季型擴縮（高峰 ~100 node、淡季 ~33 node，case 觀察段揭露）。這個 100 ↔ 33 的擺盪是 已知時間點的年度循環（NFL / NBA 賽季切換），不是不可預測的突發。case 還揭露合規驅動需要 AWS Outposts 把運算放進州內 — 這把它鎖死在 self-managed。Hard Rock 的形狀正好對照出 serverless 的適配範圍：serverless 擅長 不可預測 的突發與長尾閒置，而非 可預測且需要特定部署位置 的賽季擴縮。

核心機制：RU 計費 + 自動 scale + 冷啟動

Request Unit：把多維資源用量折算成單一計費單位

serverless 的計費核心是 Request Unit（RU）— 一個把 CPU、IO、network、storage 存取 等多維資源用量折算成的抽象單位。每個 SQL 請求依其實際消耗的資源換算成若干 RU，帳單按 RU 總量計。這跟 dedicated「按 provision 的節點數 × 時間」計費是兩種不同的成本心智模型。

RU 模型的好處是 用多少付多少 — 閒置時段不付運算費。風險是 RU 跟「人類直覺的請求數」不是線性對應：一個全表掃描的 query 可能吃掉相當於上千個點查的 RU。estimate workload 成本時，要以 資源消耗 為單位思考，不是以「請求數」。

Scope warning：RU 的具體換算係數、serverless 免費額度、scale-to-zero 的觸發閒置時間、冷啟動延遲量級、serverless 的 region / 一致性 / 規模上限，都屬 Cockroach Cloud 的計費與規格、且隨方案版本演進，三個 anchor case（DoorDash / Netflix / Hard Rock 全為 self-managed）都未揭露 serverless 計費數字。本文只給結構性判讀（RU = 多維資源折算、scale-to-zero 帶來冷啟動），具體數值與當前方案邊界需 cross-verify Cockroach Cloud Pricing 文件 與官方計費頁。

自動 scale 與 scale-to-zero

serverless 隨 workload 自動伸縮資源，無需團隊 provision。閒置時可 scale 到接近零，這正是「閒置不付運算費」的來源。對 突發 + 長閒置 的 workload（開發 / 測試環境、低流量 side project、流量極不均的早期產品），這個模型把成本壓到只反映實際活躍時段。

scale-to-zero 的代價是冷啟動 — 從近零狀態接到請求時，要先把資源拉起來，第一個請求的延遲高於 warm 狀態。對開發環境這通常可接受；對「閒置後第一個用戶請求就要快」的面向用戶 production 路徑，冷啟動是要先評估的取捨。

serverless vs dedicated 的責任與成本對照

每一行都要回到 workload 形狀判讀。

容量決策這一行是兩種模型的根本差異：serverless 把「要開幾個節點」這個決策從團隊手上拿走，對沒有容量規劃經驗或流量極不可預測的場景能降低團隊的容量規劃負擔；但對流量已知、需要性能可預測的 production，dedicated 的「自己定容量」反而是想要的控制權。

成本可預測性這一行是 serverless 的主要風險面。RU 隨用量浮動意味著 一次失控的查詢模式、一波爬蟲、一個沒加 LIMIT 的全表掃描 都會把帳單推高，而 dedicated 的成本上限就是 provisioned 容量。流量可預測的 production，dedicated 的可預算性往往比 serverless 的「用多少付多少」更重要。

操作流程：選型判讀、配置、用量驗證

第一步：用流量形狀做 serverless / dedicated 初判

選型的判讀軸是 workload 的 流量形狀，不是規模大小。

• 流量突發 + 長閒置（dev / test、低流量產品、不可預測早期 workload）→ serverless 的 scale-to-zero 與按用量計費直接受益。
• 流量穩定 + 可預測 + 需要性能可預測 → dedicated 的固定容量與可預算成本更合適。
• 流量大 + 有專屬 Platform Team + 需要跨雲 / on-prem / 特定部署位置（如 Hard Rock 的合規 Outposts）→ 兩種 managed 都不對，走 self-managed（見 vendor overview 的容量規劃段）。

判讀訊號：把過去一段時間的 QPS 畫成時間序列，看「活躍時段佔比」與「峰谷比」。活躍佔比低、峰谷比高 → serverless;活躍佔比高、波動平緩 → dedicated。

第二步：serverless 建立 cluster 並設成本上限

serverless 的成本風險來自用量浮動，所以建立後第一件事是設 消費上限，把「用量暴衝 = 帳單暴衝」的尾部風險封住。

驗證點：cluster 建立後，確認消費上限已設、且設了接近上限的告警閾值（例如達上限 80% 告警）。沒設上限的 serverless cluster 等於把成本曝險完全交給 workload 行為。

第三步：驗證 RU 消耗與預期一致

上線後監控 RU 消耗速率，對照第一步的流量形狀預估。

驗證點：RU 消耗速率若遠高於預估，通常是某類 query 的資源消耗被低估（全表掃描、缺索引、N+1 查詢）。這時要回到 query 層優化，而非直接加預算 — serverless 的計費把「低效 query」直接翻譯成「高帳單」，是一個比 dedicated 更直接的成本訊號。

第四步：評估冷啟動對 production 路徑的影響

若 serverless cluster 服務面向用戶的 production 路徑，驗證閒置後第一個請求的延遲是否在 SLO 內。

驗證點：模擬閒置後的首請求延遲，對照面向用戶路徑的 latency SLO。超出 SLO 代表這條路徑不適合 scale-to-zero，要嘛保持一定 warm 流量、要嘛改 dedicated。

失敗模式：成本失控與選型誤判

RU 用量暴衝、帳單失控（高代價情境的回退敘事）

serverless 最常見的事故是 帳單暴衝 — 一波非預期流量、一個低效查詢上線、一次爬蟲，把 RU 消耗推到遠超預算。跟 dedicated「成本上限 = provisioned 容量」不同，serverless 的成本上限要靠人為設定，沒設就沒有天花板。

這個情境的回退代價特殊之處在於 成本已經發生：rebalance 可以暫停、locality 可以改回，但已計的 RU 帳單不會退回。所以 serverless 成本失控的「回退」重點在 事前封頂 與 事中熔斷，而非事後補救。

回退與防護要素：

• 事前一定設消費上限與分級告警（接近上限前就要收到訊號），把尾部風險封在可承受範圍。
• 事中發現 RU 暴衝，先定位來源 — 是流量真的漲（業務事件），還是某個 query 模式失控（缺索引、全表掃描、無 LIMIT）。前者考慮是否該轉 dedicated，後者回 query 層修。
• 設「RU 消耗速率超過閾值就告警 + 自動限流」的 tripwire，避免單一失控 query 在無人值守時段燒完整月預算。
• 若 workload 已穩定成長到「serverless 浮動成本 > dedicated 固定成本」的交叉點，規劃轉 dedicated。

serverless → dedicated 遷移的代價

當 workload 從「突發長尾」成長為「穩定高量」，serverless 的按用量成本會超過 dedicated 的固定成本，此時要遷移。這個遷移不是改個開關 — serverless 與 dedicated 是不同的 cluster 形態，遷移意味著資料搬遷與 cutover，要走 backup / restore 或資料複製流程，並承擔 cutover 窗口。

回退敘事：把 serverless → dedicated 當成一次小型 migration 規劃 — 估資料量與遷移窗口、雙寫或 backup/restore 路徑、cutover 條件與回退條件，而非「線上無痛切換」。提早在用量逼近成本交叉點時規劃，避免在帳單已經失控時倉促遷移。

Anti-recommendation：不要因為「serverless 聽起來更現代」就把已知穩定、可預測、高流量的 production workload 開在 serverless。這類 workload 的可預算性與性能可預測性，dedicated 給得更直接，serverless 反而引入成本浮動與冷啟動兩個非必要風險。

把賽季型 / 可預測擴縮誤當 serverless 場景

可預測的擴縮（如 Hard Rock 的 NFL / NBA 賽季 100 ↔ 33 node 年度循環）不是 serverless 的適配範圍。serverless 擅長 不可預測 的突發，而可預測的擴縮可以用 dedicated 的計畫內 scale 直接規劃容量、保留性能可預測性。把可預測擴縮交給 serverless，是用「成本浮動 + 冷啟動」換一個本來就能用排程解決的問題。

修法：可預測的容量循環，用 dedicated + 排程 scale；只有真正不可預測的突發長尾才用 serverless。

冷啟動拖垮面向用戶路徑

scale-to-zero 的 serverless cluster 服務面向用戶 production，閒置後首請求冷啟動延遲超出 SLO，用戶感受到第一次訪問特別慢。

修法：面向用戶且對首請求延遲敏感的路徑，要嘛維持低頻 warm 流量避免完全 scale-to-zero，要嘛改 dedicated；scale-to-zero 留給容忍冷啟動的 dev / test / 後台 batch 路徑。

容量與觀測

必看 metric

• RU 消耗速率：serverless 成本的直接訊號，速率異常上升要立刻定位 query 來源。
• 當期累計消費 vs 上限：成本封頂的剩餘空間，逼近上限要告警。
• 冷啟動 / 首請求延遲：scale-to-zero 對面向用戶路徑的影響。
• query 資源消耗分佈：哪些 query 吃掉最多 RU，是 serverless 成本優化的入口。

容量與成本判讀

• serverless 月成本 ≈ Σ(各 query RU × 頻率)，所以成本優化等於 query 效率優化 — 缺索引、全表掃描在 serverless 直接體現為帳單。
• serverless / dedicated 成本交叉點 ≈ 「serverless 浮動成本」與「dedicated 固定容量成本」相等的用量水準，逼近交叉點是規劃遷移的訊號。
• dedicated 的容量規劃回到節點數 × replica × latency budget（見 vendor overview 容量規劃段）。

Scope warning：RU 換算係數、免費額度、serverless 的規模 / region / 一致性上限、serverless ↔ dedicated 成本交叉點的具體用量水準，均為 Cockroach Cloud 計費與規格、隨方案版本變動，非 case 揭露數字，成本建模前以 Cockroach Cloud 文件 cross-verify。

回路徑

• 9.6 容量規劃模型 流量形狀 → 計費模型對應。
• 9.7 成本邊界與 efficiency managed vs self-managed 的人力 + 資源成本權衡。

邊界與整合

Sibling deep articles

• survival goals：managed 形態下 survival goal 仍是團隊決策 — serverless / dedicated 都要對齊業務 RTO / RPO，存活機制以該文為 SSoT。
• multi-region table config：serverless 與 dedicated 對 multi-region table locality 的支援邊界不同，跨 region 強一致需求要先確認所選 managed 形態是否覆蓋。
• aurora-dsql-spanner-decision-tree：Aurora DSQL 本身是 serverless distributed SQL，三家 managed distributed SQL 的選型對比以該文為 SSoT，本文不重展。

跟 Aurora DSQL / Spanner serverless 對照

Aurora DSQL（AWS）以 serverless 為核心形態、AWS-only；Spanner 提供 managed 但計費與 scale 模型不同。三家在 serverless / managed 維度的完整對比是 aurora-dsql-spanner-decision-tree 的 SSoT，本文只處理 Cockroach Cloud 自身的 serverless / dedicated 取捨。

跟 self-managed 對照

self-managed（如 Netflix 380+ cluster、Hard Rock 合規 Outposts）給最大控制權（跨雲 / on-prem / 特定部署位置），代價是專屬 Platform Team 的運維責任。判讀軸：沒有 Platform Team → managed（serverless / dedicated）；有 Platform Team + 需要特定部署位置或跨雲 → self-managed。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游選型。
• PostgreSQL → CockroachDB migration — 從 PostgreSQL 遷入後再選 managed 形態。

何時不用本文

• 已決定 self-managed（有 Platform Team 或需要 on-prem / 合規 Outposts）→ 看 vendor overview 容量規劃段與 self-host 運維，本文的 serverless / dedicated 取捨不適用。
• single-region 小 workload 且 PostgreSQL 已夠用 → 先確認是否真需要 distributed SQL，見 vendor overview 不適用場景。

相關連結

• CockroachDB vendor overview
• 9.C40 Netflix（self-managed 需 Platform Team 的反向 = managed 入口）
• 9.C41 Hard Rock Digital（可預測賽季擴縮 vs serverless 突發適配範圍的對照）
• distributed SQL 卡
• 官方：Cockroach Cloud Documentation / Plan Your Cluster

本文是 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

本文的判讀錨點是：API compatibility 只解決入口語法的一部分。YugabyteDB 要審查 PostgreSQL 相容與 distributed operation 差異；TiDB 要額外處理 PostgreSQL → MySQL dialect / driver / tooling 轉換。Distributed SQL 會改變 transaction latency、placement、index cost、DDL、sequence、lock、backup、observability 與 incident route。

Official Documentation Route

Official documentation route 的核心責任是把 compatibility claim 固定到可回查來源。YugabyteDB compatibility 先查 YugabyteDB PostgreSQL compatibility；TiDB compatibility 先查 TiDB MySQL compatibility；本文最後檢查日是 2026-05-22。

Driver Check

Driver check 的核心責任是確認 distributed SQL 解決的是核心問題。

若主要問題是 read scaling、connection 數或 query index，先評估 read replica、pooler、partition、Citus 或 Aurora；distributed SQL 適合資料拓撲問題。

Compatibility Audit

Compatibility audit 的核心責任是把 PostgreSQL behavior 逐項對照 target。

Compatibility audit 要用 application query suite。只看 schema import 會漏掉 transaction retry、query planner、distributed index、dialect rewrite 與 latency。TiDB 路線還要加 PostgreSQL driver / SQL / type / migration tool 轉 MySQL ecosystem 的審查。

Data Topology

Data topology 的核心責任是決定資料如何分布。Distributed SQL 的成敗常取決於 primary key、tenant key、region placement 與 hot key 控制。

Topology 設計要從最高頻 workflow 開始。若核心交易每次都跨 shard，distributed SQL 的 latency 與 conflict cost 會很高。

Migration Phases

Migration phases 的核心責任是降低跨拓撲遷移風險。

CDC catch-up 要有 clear cutover LSN。Distributed SQL migration 最怕 source / target 同時有寫入後，缺少 reconciliation plan。

Application Changes

Application changes 的核心責任是讓程式接受 distributed system 的錯誤模式。

1. Transaction retry：serialization / conflict error 要可重試。
2. Idempotency：critical write 要有 natural key 或 idempotency key。
3. Latency budget：跨 region transaction 要進 SLO。
4. Pagination / ordering：distributed query 的排序成本要審查。
5. Connection / driver：target driver、TLS、pooling、load balancing 要測。

Application 若假設 single-node low-latency transaction，遷移後會在 tail latency 與 retry 行為上出現落差。TiDB 路線還會出現 driver、placeholder、SQL function、type mapping 與 error code 的轉換成本；這些要在 staging failure injection 先看到。

No-Go Conditions

No-go conditions 的核心責任是阻止把 distributed SQL 當成萬用擴容。

Distributed SQL 的價值來自拓撲匹配。若 workload 缺少自然分布邊界，導入後只是把單點瓶頸換成分散式複雜度。

下一步路由

PostgreSQL to YugabyteDB / TiDB migration 完成後，先讀 Global Distributed OLTP；若需求是 PostgreSQL 內分散式 table，讀 Citus Distributed；跨 vendor 流程讀 Database Migration Playbook。