本文 不 展開 vendor 機制細節（partition key 設計 / consistency level / RU sizing / connection management 等）— 那些屬 per-vendor deep article 的責任、本文在每個軸後 cross-link 過去。本文也 不 比較三家「誰比較強」— 三 vendor 在 workload-by-workload 適配光譜上各有位置、寫成優劣比較會誤導讀者把選型壓成單軸。

問題情境：讀者進來時的真實壓力

典型啟動壓力分兩類：

第一類、團隊評估 document / KV / multi-model NoSQL 三家、文件都說「scalable schema-less」、看不出實際取捨。讀者徵兆是「我的資料是 document-shaped 還是 KV-shaped？」「partition key 該怎麼選？」「Atlas 跟 Cosmos DB MongoDB API 不一樣的點在哪？」「Cosmos DB multi-model 是真用得到還是行銷話術？」「on-demand vs provisioned 怎麼選？」

第二類、既有 PostgreSQL / MySQL workload 撞 connection limit（surge 下 1K-5K pool 是隱性天花板、F1.7）、想換 KV 但不知道是否適合。讀者徵兆是「我已經有 Memcached、還要再加 MongoDB cache 層嗎？」「DynamoDB 適合當 OLTP 嗎？」「換 NoSQL 是不是解 connection 問題的銀彈？」

這兩類讀者進來時的 真實問題 不在 vendor 之間、在 workload 自己屬哪一型。Case anchor 覆蓋六個 unique 角度：

• 多型 document workload — 9.C38 Toyota Connected（車載 sensor schema 隨車型演進、20 個 Atlas DB blast radius 切分）
• Document 跨雲 hedging — 9.C37 Forbes（自管 → Atlas、6 個月遷移、跨雲彈性）
• 同 model 換 vendor 的 dogfood signal — 9.C30 Microsoft 365（MongoDB → Cosmos DB MongoDB API、保留 driver、wire compat 限制）
• KV-as-buffer 正向用例 — 9.C15 Tixcraft（DynamoDB 寫入緩衝、6750x 彈性、後端慢消費）
• PK 天然均勻典範 — 9.C5 Amazon Ads（90M reads/sec 年度峰值、KV pattern 純粹）
• Federated DB 真實系統 — 9.C36 Coinbase（MongoDB + DynamoDB + Memcached + mongobetween + freshness token）

Workload shape × access pattern × consistency 三軸前置判讀

進三家 vendor 對比前先回答：你的 workload 屬哪一型？三軸的組合決定 vendor 候選清單、軸不識別清楚直接比 vendor 是把選型壓成「品牌偏好」、不是工程決策。

軸 1 — 資料形狀：document / KV / 不清楚

資料形狀的核心判讀是 aggregate root 邊界是否明確 跟 schema 是否會隨產品演進新增欄位。document 適合的場景是資料天然多型、單筆記錄欄位差異大、應用層用 aggregate root 模式存取；KV 適合的場景是資料形狀固定、access pattern 數量少（< 5 種）、固定 lookup by key。

第三列的「暫緩 NoSQL」是反指標。NoSQL（特別是 DynamoDB single-table design）的核心假設是「access pattern 在設計時已知、後續變動有限」。資料模型還在探索、access pattern 半年內會大幅增減的場景、PostgreSQL + JSONB 給的彈性遠高於 NoSQL — JSONB 欄位可以演進、ad-hoc query 可以用 SQL 跑、未來釐清穩定 access pattern 後再選 NoSQL 不遲。

軸 2 — Access pattern 穩定度（KV 適用度前置判讀）

KV 適用度的核心判讀是 partition key 天然均勻度。partition key 不均勻會讓 vendor 廣告的「scale infinitely」變成「scale 到 hot partition 為止」、單一 logical key 流量超過該 partition 上限就 throttle 或 latency spike（F1.1）。

• 天然均勻 PK + 穩定 access pattern（meeting_id / player_id / message_id / user_id）→ DynamoDB / Cosmos DB Table API 適用、PK 不需 composite key 修補。Amazon Ads 用 ad_id 撐 90M reads/sec、Zoom 用 meeting_id、Capcom 用 player_id、PayPay 用 message_id、Disney+ 用 user_id — 五個 case 都揭露同一 frame：業務天然存在均勻 key 時 KV 是最自然的選擇。
• 天然不均勻 PK（event_id 一場演唱會集中 / date 時間序集中）→ 需 composite key 或 write sharding 修補。Tixcraft（9.C15）用 event_id + user_id_hash composite key 把單一熱門演唱會的 6750x spike 攤平到 partition 上 — 不是 DynamoDB 自身彈性、是 partition key 均勻分散的結果（F1.2）。
• Access pattern 變動頻繁（探索期、< 5 種 query 還會增加）→ 不適合 DynamoDB single-table design、回 RDB。Single-table 把 access pattern 編進 PK / SK 結構、增加新 query 等於改 schema、改 schema 等於重新 load 資料、成本不對。

KV 適用度判讀的延伸細節（hot partition 反模式 / composite key 設計 / adaptive capacity）見 DynamoDB partition key antipatterns。

軸 3 — Consistency 需求是否可接受 eventual

Consistency 需求的核心判讀是 跨 partition / 跨 region transaction 是否為產品契約。三家 vendor 都支援單 partition / 單 region 強一致、但 cross-partition / cross-region transaction 的機制跟限制差異大。

• 可接受 eventual / session consistency：DynamoDB（default eventually consistent reads、可選 strong）、Cosmos DB（5 個 consistency level、default session）、MongoDB（read concern 多級）— 三家都可以、選擇看其他軸。多數 KV / document workload 屬此類（social timeline、watchlist、message queue、analytics aggregation）。
• 需要強一致 cross-partition transaction：DynamoDB 跨 partition transaction 限制（單一 transaction 最多 100 個 action、跨 region 不支援）、MongoDB 4.0+ 支援 multi-document transaction 但 sharded cluster 仍有 limitation、Cosmos DB 跨 logical partition transaction 受限 — 都不如 SQL／distributed SQL 自然、應回 DB4 entry point 評估 Aurora DSQL / Spanner / CockroachDB。
• 跨 region active-active write：三家機制完全不同 — Cosmos DB multi-region write 跟 Strong consistency 是 互斥 設定（CAP 取捨硬約束、見 Cosmos DB multi-region write conflict SSoT 主寫位置）；DynamoDB Global Tables 走 LWW（last-writer-wins）conflict resolution；MongoDB Atlas 跨 region 需手動 conflict 處理。三家不在同一光譜、選擇前必看各 vendor outline 的機制段。

Migration path 三型（跨 case 合成 frame）

本段是 跨 case 合成 frame、不是單一 case 揭露 — 從 Coinbase（9.C36）/ Forbes（9.C37）/ Microsoft 365（9.C30）三 case 萃取的共通結構（F2.1）。

讀者進來時通常不是綠地、是 既有系統演進。三型遷移路徑的風險、ROI、適用條件完全不同、選錯路徑會推到錯的 vendor。

第一型：保留原 DB + 補周邊工具

不換 vendor、加 connection proxy（mongobetween / pgbouncer 類）、加 cache（Memcached + freshness token）、加 predictive scaling — 主資料層不動、應用層跟 ops 層補強。

• 代表 case：Coinbase（9.C36）保留 MongoDB Atlas、自建 mongobetween 把 60K connections/min 降到 ~2K（一個量級）、用 Memcached + freshness token 撐 1.5M reads/sec、用 ML predictive scaling 把擴容時間從 70 → 25 分鐘提前 60 分鐘
• 路徑成本：中（自建工具、需要工程資源 build & operate proxy / cache layer / ML model）
• 風險：低（主資料層不動、回滾代價小）
• ROI：保留主資料 schema + access pattern、解 driver / 部署模型 / cache 一致性瓶頸
• 適合：MongoDB（或主 DB）資料層撐得住、但應用層 connection storm / cache miss / 擴容慢卡瓶頸；團隊有工程能力 build 跟 maintain 周邊工具

延伸實作細節見 MongoDB connection management（per-vendor article、cross-link 待寫稿）。

第二型：同 DB 換託管

自管 → managed（Atlas / Cosmos DB / DocumentDB）、保留 schema 跟 access pattern、遷移期 6 個月量級。

• 代表 case：Forbes（9.C37）自管 MongoDB → MongoDB Atlas、保留 CMS schema、6 個月遷移、揭露「TCO 改善 25%」
• 路徑成本：中（dual-write + shadow read 驗證、driver 行為差異、operation runbook 重寫）
• 風險：中（dual-write 期間雙寫一致性、cutover 時點選擇）
• ROI：operation transfer（DBA bandwidth 釋放給 schema design / query tuning）+ TCO 改善
• 適合：自管 ops burden 大（DBA bandwidth 被 backup / patching / replica lag 吃光）、不想換 model

Scope warning（Forbes 25% TCO）：「25% TCO 改善」是 Forbes 特定流量規模（120M MAU、70+ Atlas region）下的數字、不普適。引用要帶條件 — 不要寫成「Atlas 比自管便宜 25%」這種 vendor-neutral 結論。實際省多少要看自管當下的 license / hardware / ops 工時分配、跟 Atlas 在你流量規模下的 pricing tier。

第三型：換 vendor 保留 model

MongoDB → Cosmos DB MongoDB API、或 MongoDB → DocumentDB — wire protocol + driver 不變、底層架構整個換、ops 模型整個換。

• 代表 case：Microsoft 365（9.C30）MongoDB → Cosmos DB MongoDB API、保留 MongoDB driver
• 路徑成本：高（dual-write per query pattern 驗證、wire compat ≠ 100% 行為相同、aggregation pipeline 跟 transaction 行為要逐項驗證）
• 風險：高（每個 query pattern 都可能踩到不相容 edge case、cutover 點選擇難）
• ROI：跨 vendor 換（Azure 生態 / multi-model API / global distribution）+ 保留應用層 driver code

Scope warning（Microsoft 365 dogfood）：Microsoft 365 是 Microsoft 自家 dogfood、case 沒揭露具體 throughput / latency / cost 數字（F2.17）。dogfood 是 高權重 selection signal（雲商賭自家旗艦產品）、但 不是 production benchmark（沒公開數字可比對）。引用要明示「dogfood signal」而非「production proof」。

Scope warning（100% wire compat）：Cosmos DB MongoDB API 廣告「100% wire compatibility」是 vendor 行銷話術、實際是「在某些 query pattern 下相容」（F2.9）。遷移時必須 dual-write per query pattern 驗證 — 不是看 vendor 文件 spec list、是用 production query corpus 跑一遍實測行為。Phase 0 audit checklist 應列出 unsupported aggregation stage、transaction edge case、index behavior 差異、change stream 跟 Change Feed 對應關係。

延伸 Cosmos DB MongoDB API vs SQL API 選型見 Cosmos DB MongoDB API vs SQL API。

第四型不在 DB3 範圍：paradigm shift 換引擎

KV → SQL 或 SQL → distributed SQL 屬 paradigm shift、應進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree。本文範圍是 DB3 三家內部選型、不展開 paradigm shift。

從 RDB 撞牆來的快速路徑

讀者若從 PostgreSQL / Aurora connection limit 撞牆過來、想評估 KV 替代、依撞牆訊號直接 route 到對應 article、不必先跑完三軸前置判讀：

• 撞 connection limit（surge 下 pool 1K-5K 隱性天花板、long-lived TCP 占滿）→ HTTP API 模型（no long-lived connection）的 KV 直接接寫入緩衝、進 dynamodb/single-table-design-pattern 的「durable queue / write buffer」段（Tixcraft 9.C15 路徑：DynamoDB 接訂單、傳統 server 慢消費）、或評估 Cosmos DB Table API
• 撞單 primary 寫入上限（單 leader 寫吞吐天花板、read replica 無法分擔寫）→ multi-primary distributed SQL 路徑、進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree 的 Path A（DoorDash 1.636 M QPS 單主寫入撞牆）
• 撞單一 DB 撐不下 + 多 workload 形狀並存（read-heavy / write-heavy / analytics 混在一個 DB）→ federated DB 模式、看 9.C36 Coinbase（MongoDB + DynamoDB + Memcached + mongobetween）+ 9.C29 Lemino（PostgreSQL → DynamoDB 揭露 RDB connection limit 隱性 bottleneck）

進 dynamodb/single-table-design-pattern 前先確認軸 1 / 軸 2 的 access pattern 穩定度跟 PK 天然均勻度 — connection limit 訊號 必要但不充分、KV 適用度 4 軸還是要走完、避免「為了解 connection 把不穩定 access pattern 硬塞 single-table」反模式。

Federated DB + system role 視角（跨 case 合成 frame）

本段也是 跨 case 合成 frame（F2.18 + F1.6）— 三個 rich case（Coinbase / Toyota / Forbes）都揭露 production 系統是 DB + 周邊工具 組合、不是單一 DB monolithic 撐起來。

讀者常誤以為「全用 X」是正解 — 全用 MongoDB、或全遷 DynamoDB、或全換 Cosmos DB。真實 production case 揭露兩個更前置的事實：(a) production 系統是 federated（多 DB 按 workload 分流）、不是 monolithic；(b) 每個 vendor 在系統中扮演 特定角色（control plane vs data plane vs cache）、不是 all-purpose store。

Federated DB by workload

Coinbase（9.C36）production 配置：MongoDB Atlas（document 主資料、identity service）+ DynamoDB（部分固定 KV workload）+ Memcached（read cache）+ mongobetween（connection proxy）+ Kinesis（event stream）。不是「全用 MongoDB」也不是「全遷 DynamoDB」、是按 workload shape 分流。

Toyota Connected（9.C38）：MongoDB Atlas 20 個 DB（microservice 拆 blast radius）+ Lambda + Kinesis + Redis + Kubernetes。20 個 DB 不是吞吐撐不住（18B txn/月 ≈ 7K txn/sec、單一 cluster 撐得下）、是 microservice ownership + blast radius 切分（F2.6）。

Forbes（9.C37）：MongoDB Atlas + 中介 abstraction layer + 50+ microservice。abstraction layer 隔離 schema 變動、避免 50 個服務都依賴 DB schema 細節（F2.3）。

三 case 揭露的共同 frame 是：寫 production 系統時假設「DB 一個服務搞定」、忽略 cache / queue / proxy / abstraction layer 跨層責任、會撞 connection limit / cache miss / cross-region replication 等隱性瓶頸。

System role：control plane vs data plane

DynamoDB 在 surge 場景能撐 nearly infinitely 不是 DynamoDB 自己神奇、是 系統架構解耦 的結果（F1.6）：

• Control plane（metadata、state、user record）：DynamoDB / MongoDB / Cosmos DB 適合 — 流量是 small payload + high QPS pattern
• Data plane（影音、大型 BLOB、media stream）：CDN / S3 / object storage、不在 DB3 範圍 — 流量是 large payload + bandwidth-bound
• Cache layer：Redis / Memcached / DAX（DynamoDB 補位）— 跟主 DB 形成跨層架構、處理讀峰值 + read-your-own-write 一致性

三個 case 揭露同一 frame：Zoom 視訊 metadata 走 DynamoDB、影音走 WebRTC / edge servers；Disney+ watchlist 走 DynamoDB、影片串流走 CDN + S3；Capcom game state 走 DynamoDB + DAX、game server 走 EKS。把影音串流塞 DynamoDB 是違反 control plane vs data plane 分離、容量規劃會錯（每筆 1KB 的 KV vs 每筆 100MB 的 media chunk 是不同 workload）。

三 vendor 對比 10 軸

下表是三 vendor 在 selection 階段的 10 軸對比。每個軸後續都有 per-vendor deep article 展開機制、本文不重複展開。

軸的延伸子段

部署 topology / 跨雲 hedging：三家 topology 是 vendor lock-in 跟 跨雲彈性 的硬取捨。Forbes 選 Atlas 不是當下省錢（自管 MongoDB 也可以、TCO 改善是副作用）、是 未來雲商策略尚未底定 的 hedging — Atlas 提供 AWS / GCP / Azure 三家部署、未來換雲不用換 DB（F2.10）。對照 DynamoDB / Cosmos DB / Spanner / Aurora 都是單雲鎖定 — 選了就跟著該雲商生態走。團隊雲商策略已底定（深度用 AWS / Azure / GCP 其一）時、單雲 vendor 通常較划算（更好的 IAM 整合、更深的 ops 工具、單一 support 通道）。跨雲價值真正成立是 策略不確定 或 合規要求多雲 場景。

Capacity 抽象：三家 capacity 抽象的 思維遷移成本 可能高過 vendor 廣告的價差（F2.12）。MongoDB 用 CPU + IOPS + working set RAM 三軸思維、跟自管 PostgreSQL / MySQL 類似、團隊轉換成本低。DynamoDB 用 WCU/RCU 抽象、要學「估每個操作消耗多少 unit」、加上 on-demand / provisioned / adaptive capacity 三模式選擇。Cosmos DB 用 Request Unit（RU）抽象、1 RU ≈ 1 KB document 的 strong read 成本、寫 ~5 RU、複雜 query 數百 RU — 工程師要學會用 RU 思考、不是用 CPU 思考、團隊知識遷移成本可能高。容量規劃延伸見對應 vendor 的 sizing article。

Partition / shard key 可逆性：三家 不在同一光譜、是選 vendor 前必做的 access pattern audit 重點（F2.15）。MongoDB reshardCollection（4.4+）可改、但成本高、需要 cluster downtime 或長時間 background migration。DynamoDB partition key 技術上可改、實作上用 backfill（建新 table、新 PK、雙寫舊新、cutover）— ops 工作量大但可逆。Cosmos DB partition key 不可改、改 partition key 等於 export-recreate-import — 對 1TB+ 資料是大型 migration 工程。三家不可逆性遞增、選 Cosmos DB 前必須前期完整 access pattern audit、不能「先上 production 之後再調」。

Consistency model：三家機制設計哲學不同。MongoDB read concern 是 per-operation 選擇（同一 client connection 可以混用）；DynamoDB strong vs eventual 是 per-read 選項（write 端統一強一致）；Cosmos DB 5 個 level 是 account-level default + per-request override、且 Strong 跟 multi-region write 互斥（CAP 硬約束）。設計上 MongoDB 最 flexible、Cosmos DB 最 explicit、DynamoDB 介於中間。延伸機制細節見 Cosmos DB consistency levels engineering、Cosmos DB multi-region write conflict（SSoT 主寫位置）。

Multi-model 差異化：Cosmos DB 是 唯一單一服務支援 5 API 的雲商 DB（SQL / MongoDB / Cassandra / Gremlin / Table）— 對照 AWS 走多產品覆蓋（DynamoDB KV + DocumentDB MongoDB-compat + Neptune graph + Keyspaces Cassandra-compat）、GCP 走多產品覆蓋（Firestore + Spanner + Bigtable）。multi-model 的差異化價值是 減少多 DB 並存運維 — 一個產品團隊只養一個 service、一套 IAM、一套 backup / DR、一套 monitoring。但 是否真用上 multi-model 要看團隊實際 workload — 多數團隊只用 1-2 個 API、單一 model 的競品（DynamoDB / MongoDB）可能更專注（F2.16）。

失敗模式（cross-vendor 反模式）

下列七條是三 vendor 都會踩、跨 case 共通的反模式。Per-vendor 特定反模式（例如 DynamoDB on-demand 隱性 hot partition、MongoDB schema 三代並存）在 per-vendor deep article。

反模式 1：把 DynamoDB 當 OLTP

訊號：access pattern 還在探索期、5+ 種 query 還會增加、強一致 cross-partition transaction 是產品契約。應回 PostgreSQL / Aurora、不是繼續加碼 DynamoDB single-table design。

DynamoDB 的 正確 用法包含 control plane KV（Zoom / Disney+ / Capcom）跟 durable queue / write buffer（Tixcraft 9.C15 揭露的非 OLTP 正向用例、F1.3）— DynamoDB 接「訂單」寫入、不是即時生效、是讓 traditional server（金流 / 票庫）用自己能承受的速度消費。這層解耦讓「前端可以擴 130 倍、後端不用同步擴」。

反模式 2：把 MongoDB 當 KV

訊號：access pattern 固定、PK 天然均勻、不需要 aggregation pipeline、document 內部從不展開（只查 root 欄位）。

應改 DynamoDB / Cosmos DB Table API。MongoDB 在這場景的 overhead（document overhead / connection model / aggregation engine 未用上）不划算 — KV vendor 的單筆讀寫成本更低、scaling 模型更簡單。

反模式 3：把 Cosmos DB 當跨雲服務

訊號：團隊評估 multi-cloud DR / 跨雲 portability、看到 Cosmos DB 文件強調「global distribution」就以為支援跨雲。

Cosmos DB 是 Azure-only、global distribution 指 Azure 內跨 region。想跨雲應改 MongoDB Atlas。multi-model 差異化是 Azure 生態內 的價值（F2.16）— 一旦離開 Azure、Cosmos DB 的所有獨特優勢都不存在。

反模式 4：federated DB 假設「全用 X」

訊號：寫架構設計時假設「DB 一個服務搞定」、不規劃 cache / queue / proxy / abstraction layer。

Production 真實系統都是 federated（Coinbase / Toyota / Forbes 都是）。寫架構時假設一個 DB 搞定會撞 connection limit（surge 下 RDB 第一個爆點、F1.7）/ cache miss（單靠 DB 撐不住讀峰值）/ cross-region replication（跨 region 一致性處理錯）等隱性瓶頸。預先設計 federated topology + 跨層責任分配、不是事後補。

反模式 5：誤判 dogfood case 數字

訊號：引用 Microsoft 365 / Amazon Prime Day 等 dogfood case 時、把它當 production benchmark、抄具體數字當 sizing 依據。

Dogfood case 數字常 不公開 或 不適用 customer-facing（F2.17 + F1.10）— Amazon Prime Day 「90M reads/sec」是年度峰值最高一秒不是平均、Microsoft 365 直接沒給數字、Google Spanner「10 億 req/sec」是 Google 全使用者加總不是單客戶配額。寫架構時引用要明示 selection signal（雲商賭身家、值得當高權重 vendor 訊號）vs production benchmark（具體 sizing 數字）— 兩者不可混為一談。

反模式 6：partition key 一上 production 才發現不可逆

訊號：選 Cosmos DB / DynamoDB 時、partition key 設計沒做完整 access pattern audit、上 production 一段時間後發現 hot partition、想改 PK。

三家不在同一光譜（見前段對比表）— MongoDB shard key 4.4+ 可改但成本高、DynamoDB 可 backfill 改、Cosmos DB 不可改 必 export-recreate。選 Cosmos DB 前要前期完整 access pattern audit、列所有預期 query 跟對應 PK 訪問頻率、確認最熱 PK 流量在單一 partition 容量上限內（F2.15）。

反模式 7：wire compatibility 當 100% 行為相同

訊號：選 Cosmos DB MongoDB API 或 DocumentDB、看到「MongoDB compatible」就假設 MongoDB driver 跑得起來就是相容、跳過 query pattern 驗證。

Wire compat ≠ 行為 100% 相同（F2.9）。Cosmos DB MongoDB API 廣告「100% wire compatibility」是行銷話術、實際是「在某些 query pattern 下相容」— aggregation pipeline 某些 stage 不支援、transaction edge case 行為差異、index 行為差異都會踩到。遷移必須 dual-write per query pattern 驗證、不是看 vendor spec list。

不該選 DB3 的訊號（升 SQL / 升 distributed SQL 路徑）

下列四條訊號出現時、選擇應跳出 DB3 範圍。

• JOIN-heavy + 強 normalize workload：應留 PostgreSQL（包括 PostgreSQL + JSONB 混合方案）、不該塞 NoSQL 再 $lookup。aggregation pipeline 的 $lookup 性能遠不如 SQL JOIN、在 sharded cluster 還有限制。
• 強一致 cross-region transaction 是產品契約：應進 DB4 entry point 評估 distributed SQL（CockroachDB / Spanner / Aurora DSQL）。三家 NoSQL 的 cross-region transaction 都有 limitation、不該當主路徑。
• 大流量 + 跨業務 fleet 治理：Aurora 200 cluster 模式（9.C4 DraftKings 揭露的 business sharding fleet）可能更合適、進 Aurora fleet 治理。NoSQL 的 fleet 治理工具鏈（cluster lifecycle / cross-cluster query / unified IAM）通常不如 managed SQL 成熟。
• 資料模型還在探索 + access pattern 變動快：暫緩 NoSQL 選型、用 PostgreSQL + JSONB 過渡。JSONB 給 document-like flexibility、SQL 給 ad-hoc query power、未來釐清穩定 access pattern 後再選 NoSQL 不遲。

下一步路由（per-vendor outline 子組）

讀者識別 workload type（軸 1-3）+ migration path（三型）+ system role（federated / control plane）後、進對應 per-vendor 子組繼續深化。

MongoDB 子組

• 入門：schema design pattern（contract layer 三選一：DB 層 validator / app 層 abstraction / 混合）
• 容量：shard key selection（單 cluster vs 多 cluster blast radius、Toyota 20 DB 模式）
• Migration：migrate to Atlas（同 DB 換託管型）

DynamoDB 子組

• 入門：single-table design pattern（access pattern 設計 + 適用度前置判讀）
• 機制：consistency model optimization（strong vs eventually consistent 取捨）

Cosmos DB 子組

• 入門：MongoDB API vs SQL API（API model 選型、四層 framing）

跨層架構（federated DB / cache / proxy）

跨層架構的延伸內容見對應 per-vendor connection management / cache layer article（後續會寫）— 本文只在軸 2 / federated frame 點到、不展開機制。

進 DB4 evaluation

若需要強一致 cross-region SQL / paradigm shift（KV → distributed SQL 或 SQL → distributed SQL）、進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree。

Knowledge card 路由

本文涉及的 knowledge card：

• document-store — document model 的核心概念跟 aggregate root 邊界
• hot-partition — KV vendor 的 partition 容量上限機制
• database-sharding — shard key 跟 partition key 設計
• consistency-level — strong / eventual / session 三類取捨
• vendor-lock-in — 單雲 vs 跨雲的 hedging 取捨
• distributed-sql — 跳出 DB3 進 DB4 的概念入口

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