教學路線：SQL baseline 與交易演進

PostgreSQL 服務頁的教學目標是建立 SQL baseline。讀者讀完後要能用 PostgreSQL 理解 transaction、schema evolution、query boundary、connection pressure 與 managed / distributed SQL 的比較基準。

定位：OLTP 預設、SQL 工程深度

PostgreSQL 跟 MySQL 是兩大 SQL OLTP 主流、但設計取捨明顯不同：

• PostgreSQL 偏 特性深度 — JSON、GIS、full-text search、partial index、CTE、window function 都成熟
• MySQL 偏 簡單 query 效能 + 分片生態 — Vitess / PlanetScale 提供超大規模 database sharding

選 PostgreSQL 的核心訴求：需要進階 SQL 特性、需要長期 schema evolution 彈性、信任 community-driven 演進、想避免單一 vendor lock-in（PostgreSQL 是 open source、可跨雲 / on-prem）。

容量特性

PostgreSQL 沒有「vendor 給的容量數字」、要靠 instance 配置 + tuning 推估。但有幾個工程上限要知道：

單一 primary 寫吞吐：

• 一般 m5.4xlarge 級 instance：5K-10K WPS（依 schema、index、commit fsync）
• 高階 r6i.16xlarge + io2 storage：30K-50K WPS
• 超過這個級別 → 應用層 database sharding 或換 Aurora / Spanner

Connection 上限：

• 預設 100 connection、每個 connection ~10MB RAM
• 1000+ connection 必須 pgBouncer / PgCat 共享 pool
• 對應 9.C29 Lemino case — RDB connection limit 是 surge 場景的隱性 bottleneck

Read replica：

• streaming replication：1 個 primary + 多個 standby（async / sync）
• 跨 AZ replication lag 通常 < 100ms、跨 region 可能秒級
• 跟 Aurora 比、自管 PostgreSQL replication lag 較大

Storage 上限：

• 單一 table 32 TB（PostgreSQL 設計上限）
• 實務上單表超過 1 TB 開始有 vacuum / index 問題、建議 partition

適用場景

1. 多用途 OLTP、複雜查詢：

• 複雜 JOIN、CTE、window function、subquery
• 訂單系統、會員系統、訂閱方案、權限 RBAC
• 需要 strong consistency + ACID transaction

2. JSON / 半結構化資料：

• JSONB column 支援 indexing、partial query
• 比 MongoDB 適合 主要結構化 + 部分 JSON workload
• 不適合主要 document workload（用 MongoDB / Cosmos DB）

3. 地理 / 全文檢索：

• PostGIS 是業界標準 GIS extension
• 全文檢索（ts_vector）對中等規模夠用、超大規模用 Elasticsearch

4. 進階特性需求：

• partial index（WHERE 條件下才建 index）
• exclusion constraints（避免 booking 重疊）
• range types（時間 / 數字範圍）
• logical decoding / CDC（Debezium、pgcapture）
• foreign data wrapper（query 跨 DB）

5. 跨雲 / on-prem 部署：

• 不想 vendor lock-in
• 可用 Patroni / Stolon / pg_auto_failover 做 HA
• 對應 1.11 全球分散式 OLTP 的 CockroachDB / Aurora DSQL 比較段

6. 中小規模高峰場景：

• 流量 < 10K WPS 級別、PostgreSQL 自管或 RDS 通常夠
• 流量更高、考慮 Aurora（同 wire protocol、storage 升級）

不適用場景

1. 極高寫入吞吐（單機 > 50K WPS）：

• 必須進入 database sharding 或分散式 SQL
• 替代：CockroachDB、TiDB、Spanner、應用層 sharding

2. 全球 multi-region active-active write：

• PostgreSQL 是 single primary、不支援 multi-region active-active
• 替代：Aurora DSQL、Spanner、CockroachDB multi-region

3. KV 簡單查詢 + sub-10ms p99：

• PostgreSQL connection 開銷 + parsing + planning 已經 1-3ms
• KV-pattern workload 用 DynamoDB / Redis / Cosmos DB 更便宜更快

4. 大規模 OLAP：

• PostgreSQL 定位在 OLTP，analytics workload 交給 OLAP 系統
• 大數據分析用 ClickHouse / BigQuery / Snowflake / Redshift / Synapse

5. 連線量極大 SaaS（每個用戶一個 connection）：

• 即使有 pgBouncer、超大連線量仍是 PostgreSQL 結構性限制
• 對應 9.C29 Lemino 案例 — 流量上升 connection 爆是換 DynamoDB 的主因

跟其他 vendor 的取捨

vs MySQL：

• PostgreSQL：SQL 特性深、JSON / GIS / window 完整、replication 較簡單但 lag 較大
• MySQL：簡單 query 效能好、replication 機制成熟、Vitess 分片生態強
• 選 PostgreSQL：需要進階 SQL、複雜 query、JSON workload
• 選 MySQL：高併發簡單 query、需要 sharding、已用 MySQL 生態

vs Aurora（同 PostgreSQL wire protocol）：

• PostgreSQL：自管 / RDS、特性接近 upstream、跨雲可用
• Aurora：AWS managed、storage / compute 分離、更多 read replica
• 選 PostgreSQL：跨雲、想最新特性、預算敏感
• 選 Aurora：AWS 生態、需要更快 failover + 更多 read replica
• 詳見 Aurora vendor page

vs CockroachDB（PostgreSQL wire protocol 相容）：

• PostgreSQL：single-primary OLTP、SQL 特性完整
• CockroachDB：multi-region 強一致 SQL、PostgreSQL wire 相容但部分特性缺
• 選 PostgreSQL：single-region 或 read replica 跨 region 夠
• 選 CockroachDB：必須 multi-region active-active write
• 詳見 1.11 全球分散式 OLTP

vs Spanner / Aurora DSQL（全球分散式 SQL）：

• PostgreSQL：傳統設計、跨 region 是 async replication
• Spanner / Aurora DSQL：全球線性化、跨 region 強一致
• 選 PostgreSQL：90% 場景夠用、便宜、容易
• 選 Spanner / Aurora DSQL：金融交易、ticketing inventory、必須全球強一致

vs DynamoDB：

• 詳見 1.10 KV / Document DB 容量規劃 的 connection model 對比段

vs Neon（PostgreSQL serverless）：

• PostgreSQL：standard、自管或 RDS
• Neon：branch-based、scale-to-zero、適合 dev / preview environment
• 選 Neon：dev / preview、稀疏 workload、CI 用
• 選 PostgreSQL：production sustained workload

容量規劃要點

1. Connection pool 必須有：

• 直接連 1000+ connection 會壓垮 PostgreSQL
• pgBouncer（最簡單、transaction pooling）
• PgCat（rust 寫的進階替代、支援 sharding）
• application 層 pool（HikariCP、SQLAlchemy pool）
• 通常組合使用：application pool 30-50 connection × 多 instance → pgBouncer 共享 → PostgreSQL 200 connection
• 對應 Connection Pool 卡片

2. Replication 配置：

• streaming replication：async / sync / quorum
• 跨 AZ async：lag 通常 < 100ms、failover 1-2 分鐘
• 跨 AZ sync：lag 接近 0、但寫入要等 standby ack、會降寫吞吐
• 跨 region 通常 async
• HA 工具：Patroni（最常見）、pg_auto_failover、Stolon

3. Vacuum 跟 bloat 治理：

• PostgreSQL MVCC 會留下 dead tuples、必須 vacuum
• autovacuum 配置：throttle 大表、避免在 peak 跑
• bloat 監控：pg_stat_user_tables 看 dead_tup ratio
• 大表 vacuum 可能要 hours、影響 maintenance window

4. 大表 partitioning：

• 單表 > 1 TB 建議 partition（按時間、按 tenant）
• partition pruning 讓 query 只掃需要的 partition
• partition 限制：cross-partition unique constraint、跨 partition join 較慢

5. Index 策略：

• 預設 B-tree、適合大多數 query
• partial index 對 boolean / status column 特別有用
• GIN / GiST 對 JSON / full-text / GIS
• index 太多會拖累寫入、定期 review 未用 index（pg_stat_user_indexes）

安全、DR 與角色分工

PostgreSQL 的 production 完整性不只來自 SQL 特性，也來自資料存取、備份復原、升級責任與事故證據的分工。這一段補上 PG baseline 原本留在 limitation 的三個缺口：Security / RLS / audit logging、cross-region DR、application developer vs DBA / SRE 視角。

Access control / RLS 的判讀重點是把資料責任放在資料層與 application 層之間分工。PostgreSQL 支援 role、grant、schema、function security 與 row-level security；但 RLS 會把授權邏輯拉進 database，適合 multi-tenant row isolation、資料平台或共享 reporting schema，日常 OLTP 仍要保留 application authorization 與 audit trail。

TLS / credential 的判讀重點是連線安全與憑證生命週期。Self-managed PostgreSQL 要處理 server cert、client cert、DB user rotation 與 connection pool 重連；managed PostgreSQL 常把 certificate、IAM auth 或 secret integration 交給平台，但 application pool、migration tool 與 read replica 仍要一起更新。

Cross-region DR 的判讀重點是 RPO / RTO 與資料一致性。自管 PostgreSQL 可用 streaming replication、WAL archiving、PITR 與 Patroni 做 region failover；Aurora 把 backup、PITR 與 Global Database 交給 AWS；真正 active-active 或 global strong consistency 需求要回到 CockroachDB、Spanner 或 Aurora DSQL，single-primary PostgreSQL 保留為 region failover 與 async DR 路線。

Developer / DBA split 的判讀重點是把日常責任寫進流程。Application developer 擁有 query shape、transaction boundary、repository adapter 與 migration contract；DBA / SRE 擁有 backup、replication、pooler、extension、vacuum、index maintenance 與 DR drill；release gate 需要把兩邊 evidence 合在同一份 decision log。

Managed PG 與相容變體路由

PostgreSQL wire protocol 已成為 managed SQL 與 distributed SQL 的相容目標。選型時要區分「PostgreSQL 本體」、「managed PostgreSQL」、「PostgreSQL-compatible distributed SQL」與「PostgreSQL extension ecosystem」四種不同責任。

Managed PG 變體的引用規則是先查 compatibility，再談 migration。Extension whitelist、backup / restore API、logical replication 支援、connection endpoint 行為與 pricing 都是時間敏感 claim；實作前要回到官方文件確認版本，並把確認日期留在 migration plan 或 decision log。

Deep article + Migration playbook（已完成）

補充正文路由

當前 deep article、migration playbook、補充正文與 hands-on 已 cover replication / HA / OSC / connection / CDC / sharding / multi-master / MVCC / query opt / index / partitioning / JSONB / FTS / extension（含 TimescaleDB / pgvector / PostGIS）/ backup / slot / SQL features / upgrade / migration / security / DR / managed variant 等維度。下列補充正文用來承接 overview 中提到的延伸議題：

• Logical decoding plugins deep dive：wal2json / pgoutput / decoderbufs 對位、CDC pipeline 整合
• pg_partman advanced：retention 跟 child partition 自動 management
• Connection pooler comparison：PgBouncer vs Pgcat vs Odyssey 細部對比
• Aurora I/O-Optimized vs standard：cost model 取捨
• AlloyDB / Cloud SQL 比較：GCP managed PG 選型

上述補充篇已完成正文，並保留既有引用路徑。Logical decoding 接 Logical Replication + Debezium 與 Replication Slot Management；pg_partman advanced 接 Declarative Partitioning；pooler comparison 接 Connection Scaling 與 pgBouncer Config；Aurora cost 接 → Aurora；AlloyDB / Cloud SQL 接 Managed PG Comparison。

案例對照

PostgreSQL 沒有直接的 09 case（多數 09 case 用 managed vendor）、但作為 baseline 跟遷移源頭 在許多 case 出現：

已知 Limitation 與 Audit 紀錄

本 vendor 頁的 22 篇 deep article + 6 篇 migration playbook 經過 4-reviewer audit（A 寫作規範 / B 跨檔一致性 / C 技術準確性 / D 框架偏誤）、Phase 1-3 修法完成。承認以下 limitation：

• PG narrative bias：pgvector / TimescaleDB / extension-ecosystem / Citus 四篇對「PG 取代專業 DB」描述偏 PG-favoring；對手 vendor（Pinecone / InfluxDB / Vitess）的優勢段相對簡短。讀者選型時、請以 cost / ops / scale 三軸綜合判斷、不依本 vendor 頁單一視角。
• Anti-recommendation 深度不一：bdr-multi-master / extension-ecosystem 有「99% 不需要」明確邊界、其他篇章邊界較柔（如「Vector 量 > 5-20M」是粗略門檻）。實際 production 決策請參考多 vendor 對照 + 自家 workload 量測。
• Sibling cross-link 狀態：MySQL ↔ PG sibling、PG 既有 ↔ 新章節 cross-link 已補（refer #136 卡）；本輪同步補 Aurora / CockroachDB / Spanner / Cosmos DB / DynamoDB vendor 頁的反向 sibling 路由，剩餘精修可在各 migration playbook 補更細的 step-by-step 對照。
• 時間敏感 vendor claim：Aurora DSQL（2024-12 preview / 2025-05 GA）/ pgvector（0.8 iterative scan）/ TimescaleDB version matrix / DSQL extension 支援範圍持續演進、本 vendor 頁以 2025-2026 公開狀態為準、實作前請以 vendor 官方 docs 為準（refer #137 卡）。
• 補充維度已正文化：Security / RLS / audit logging、cross-region DR、application developer vs DBA 視角分工、YugabyteDB / TiDB migration playbook、specialized PG variants 已補成正文。本輪也補上跨 vendor 反向連結與時間敏感 claim 路由；下一輪可集中在 migration playbook 的操作步驟與 lab 化。

詳細 audit findings 跟修法見 #136 Sibling Vendor Cross-Link Bidirectionality / #137 Vendor Feature 時間敏感性 / #138 Cross-Reviewer Convergence。

常見陷阱

• connection 沒 pool 直接連：1000 application instance × 30 connection = 30K connection、PostgreSQL 撐不住
• 沒 vacuum 治理：dead tuple 累積、table bloat、query 變慢
• 大表沒 partition：> 1 TB 單表的 vacuum / index rebuild 變成事故
• index 不 review：寫吞吐被舊 index 拖垮
• 跨 AZ sync replication 給寫入吞吐高的 workload：每次 commit 等 standby ack、寫吞吐減半
• logical replication 拖太多 publication：可能造成 primary WAL 堆積、disk 爆

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：MySQL vendor、Aurora vendor（managed PostgreSQL）
• 操作：PostgreSQL Hands-on（local lab、pool、PITR、migration evidence、HA drill）
• 上游：1.1 高併發資料存取、1.3 Transaction Boundary
• 下游：1.10 KV / Document DB 容量規劃（PostgreSQL 不適用時的替代）/ 1.11 全球分散式 OLTP（PostgreSQL 不夠用時的升級路徑）
• 跨模組：9.5 瓶頸定位流程 — connection / replication lag / vacuum 都是 PostgreSQL 常見 bottleneck 源
• 官方：PostgreSQL Documentation

教學路線：高併發 OLTP 與分片生態

MySQL 服務頁的教學目標是把「簡單 SQL 查詢」推進到高併發 OLTP、replication、online schema change 與 sharding governance。讀者讀完後要能判斷 MySQL 何時是成熟預設、何時已經進入 Vitess / PlanetScale 或 application sharding 的討論。

定位：高併發簡單 SQL + 強分片生態

MySQL 跟 PostgreSQL 是 SQL OLTP 兩大主流、但設計取捨明顯不同：

• MySQL 偏 簡單 query 效能 + 分片生態 — InnoDB clustered index 對 primary key range query 特別快、Vitess 提供超大規模透明 database sharding
• PostgreSQL 偏 特性深度 — 詳見 PostgreSQL vendor page

選 MySQL 的核心訴求：需要超大規模分片（> 100 TB、> 100K WPS）、簡單 query 為主、已用 MySQL 生態工具鏈（gh-ost、pt-online-schema-change）。

容量特性

單一 primary 寫吞吐：

• 標準 InnoDB：10K-30K WPS（依 row size、commit sync、index 數量）
• 高階 instance + 優化 schema：50K-100K WPS
• 超過此級別 → Vitess sharding 或 PlanetScale

Connection 上限：

• 預設 max_connections = 151、實務常設 1000-5000
• 每個 connection thread stack ~3 MB + session buffer 累積、active 高峰時 ~8-10 MB（thread + sort/join buffer）
• 仍建議 ProxySQL / connection pool 限制 backend connection 數

Replication：

• async / semi-sync / GTID-based
• 跨 AZ async lag 通常 < 100ms
• 跨 region 通常用 chain replication 或 binlog 同步

Storage 上限：

• 單一 table 64 TB（InnoDB 設計上限）
• 實務超過 1 TB 表建議分片

適用場景

1. 大規模 OLTP + 分片需求：

• 流量 > 50K WPS、必須進入 database sharding 設計
• 用 Vitess / PlanetScale 透明 sharding、應用層幾乎不必改
• 對應產業：超大網路服務（GitHub、Shopify、Slack）

2. 簡單 query 為主：

• primary key lookup、簡單 range query
• 不太用 CTE、window function、複雜 JOIN
• InnoDB clustered index 對這類 workload 特別快

3. 既有 MySQL 生態工具：

• gh-ost / pt-online-schema-change（online schema migration）
• Orchestrator（HA topology 管理）
• ProxySQL（query routing + connection pool）
• Maxwell / Debezium MySQL（CDC）

4. 強一致 transaction 但容忍部分 SQL 功能缺失：

• 不需 partial index、不需 JSONB indexing
• 不需 PostGIS、用 spatial extension 夠

5. Aurora MySQL（managed 路徑）：

• 從自管 MySQL 上 AWS、保留 wire protocol
• 詳見 Aurora vendor page

不適用場景

1. 需要 PostgreSQL 等級的 SQL / JSON 特性：

• 複雜 CTE、recursive query、window function
• JSON Schema validation、JSONB GIN indexing
• PostGIS 等深度 extension

2. 全球 multi-region active-active write：

• MySQL 設計是 single primary、跨 region 是 async
• 替代：Aurora DSQL、Spanner、Vitess multi-cluster

3. 大規模 OLAP：

• MySQL 定位在 OLTP，analytics workload 交給 OLAP 系統
• 替代：ClickHouse、BigQuery、Snowflake

4. KV 簡單查詢 + sub-10ms p99：

• 跟 PostgreSQL 一樣有 parsing / planning 開銷
• 替代：DynamoDB、Redis

跟其他 vendor 的取捨

vs PostgreSQL：

• 詳見 PostgreSQL vendor page 對比段
• 摘要：MySQL 適合超大規模分片、PostgreSQL 適合進階 SQL 特性

vs Aurora MySQL（同 wire protocol）：

• MySQL（自管 / RDS）：可跨雲、彈性高
• Aurora MySQL：AWS managed、storage / compute 分離、更多 read replica
• 選自管 MySQL：跨雲需求、預算敏感
• 選 Aurora MySQL：AWS 生態深、需要 storage scaling

vs PlanetScale（Vitess managed）：

• MySQL（自管 + Vitess）：完全控制、可自管分片
• PlanetScale：managed Vitess、branch-based schema migration
• 選 MySQL + Vitess：team 有能力管 Vitess、預算敏感
• 選 PlanetScale：想 zero ops、branch-based workflow

vs TiDB：

• MySQL：single-primary、傳統分片靠 Vitess
• TiDB：MySQL wire protocol 相容、HTAP（OLTP + OLAP 同庫）、跨 region 強一致
• 選 MySQL：已有 MySQL 投資、不想換引擎
• 選 TiDB：需要跨 region 強一致 + OLAP 同庫

vs Vitess（self-managed sharding layer）：

• Vitess 本質是 MySQL 上層的 sharding layer
• 由 YouTube 設計、捐贈 CNCF
• 適合超大規模 MySQL 集群、需要透明 sharding

vs DynamoDB（document/KV 替代）：

• MySQL：SQL、有 transaction、ad-hoc query、connection-based
• DynamoDB：KV、partition 透明、無 connection 限制、5 個 9 SLA
• 選 MySQL：需要 ad-hoc query、複雜 JOIN、SQL transaction
• 選 DynamoDB：access pattern 固定、AWS-only、想避免 connection limit 問題
• 詳見 1.10 KV / Document DB 容量規劃 的 connection model 對比

vs Spanner / CockroachDB / Aurora DSQL（distributed SQL）：

• MySQL + Vitess：自管 sharding、operational 重、跨雲可用
• Spanner / CockroachDB / Aurora DSQL：分散式 SQL、跨 region 強一致、transparent sharding
• 選 MySQL + Vitess：已有 MySQL 投資、有能力管 Vitess、預算敏感
• 選 distributed SQL：需要 multi-region 強一致、不想自管 sharding
• 詳見 1.11 全球分散式 OLTP

vs MongoDB（document 替代）：

• MySQL：SQL + JSON column 補充
• MongoDB：document 為主、aggregation pipeline 強、schema-flexible
• 選 MySQL：主要結構化、少量半結構化
• 選 MongoDB：document 占主要 schema、aggregation 工作負載

容量規劃要點

1. Sharding 是 MySQL 大規模的核心：

• 單一 MySQL primary 寫吞吐有上限
• Vitess / PlanetScale 用 keyspace + shard 切分
• shard key 設計類似 DynamoDB partition key — 必須均勻
• 大規模案例：Shopify（多 shard 分散）、Slack（per-team sharding）

2. Online schema change 是必備：

• ALTER TABLE 直接跑會 lock 整個 table
• gh-ost（GitHub）/ pt-online-schema-change（Percona）/ Vitess online DDL 用 ghost table 漸進 migrate
• 大表 schema change 可能跑 hours / days、要排程

3. Replication 跟 GTID：

• GTID-based replication 比 binlog position 容易管 topology
• semi-sync replication 保證至少一個 standby ack 才 commit
• async replication 高吞吐但 lag 較大

4. Connection management：

• ProxySQL 是 MySQL 生態的 connection pool 標準
• 提供 query routing（讀 → replica、寫 → primary）
• 對應 9.C29 Lemino case — RDB connection limit 議題對 MySQL 同樣適用

5. InnoDB tuning：

• innodb_buffer_pool_size：dedicated server 70-75%、shared server 30-50%（詳見 InnoDB Tuning）
• innodb_flush_log_at_trx_commit：1（durable）vs 2（faster）vs 0（fastest, 不安全）
• innodb_io_capacity：依 storage 類型調整

Anti-recommendation 與升級路由

MySQL 的成熟生態容易讓讀者過早引入重工具。這一段補上 deep article audit 提到的 anti-recommendation 缺口：先說何時維持簡單 MySQL 路徑，再說何時升級到 ProxySQL、Orchestrator、gh-ost、Vitess、PlanetScale 或 distributed SQL。

Replication 的簡單路徑是 GTID + async replica + 明確 read routing。當 failover 仍靠人工判斷、replica re-pointing 反覆出錯、或 semi-sync fallback 沒有被監控時，才需要把 Orchestrator、ProxySQL 與 incident runbook 放進同一條 HA 路徑。

Online schema change 的簡單路徑是先判斷 MySQL 8.0 instant / inplace DDL 能否 cover。只有大表 rewrite、長時間 metadata lock、FK / trigger 複雜互動或 maintenance window 不足時，才讓 gh-ost / pt-online-schema-change 成為主線工具。

Sharding 的簡單路徑是延後到資料形狀穩定後再做。Vitess 能把 MySQL 推到超大規模，但它也引入 VTGate、VTTablet、VReplication、VSchema、resharding workflow 與跨 shard transaction 邊界；shard key 還沒穩定時，應先用 schema、index、read replica、partition 與容量治理延長單 primary 壽命。

Managed sharding 的簡單路徑是先確認團隊想轉移哪一層責任。PlanetScale 解的是 Vitess operation、branch-based schema workflow 與 managed failover；FK、cross-shard query、connection pool 與 cost model 仍要在 migration playbook 中驗證。

Deep article + Migration playbook（已完成）

補充正文路由

當前 deep article、migration playbook、補充正文與 hands-on 已 cover ops / schema / failover / tuning / SQL features / sharding / backup / migration / security / audit / document / OLAP / memory / metadata lock 等維度。下列補充正文用來承接 overview 中提到的延伸議題：

• Encryption at rest + TLS in transit + key management：對應 PG TLS-mTLS 議題
• Audit log + SIEM 整合：MySQL Enterprise Audit Plugin 跟 Splunk / Elastic Security 整合
• MySQL Document Store（X-Protocol）：少用但對特定 use case 有興趣
• Multi-source replication topology：1 個 replica 從 N 個 primary 拉、用於 sharded environment 整合
• HeatWave（MySQL OLAP add-on）：Oracle 推的 HTAP solution、跟 ClickHouse / Snowflake 對比
• Cross-buffer memory contention deep dive：buffer pool / connection thread / temp table / sort buffer 之間的 RAM 競爭、跟 OS swap 互動
• Metadata lock deep dive：DDL / long-running SELECT / FK 互動造成的 stalls

上述補充篇已完成正文，並保留既有路由。Encryption / TLS / key management 接 TLS / mTLS 與 Secret Management；audit log 接 Audit Log 與 07 資安資料保護；Document Store 接 MongoDB vendor 與 1.10 KV / Document DB 容量規劃；multi-source replication 接 Replication Topology；HeatWave 接 OLAP 替代路由；memory contention 接 InnoDB Tuning；metadata lock 接 Lock Contention 與 Online Schema Change Tools。

已知 limitation（多輪 audit 結論）

17 篇 batch 跑過 4-reviewer audit（寫作規範 / 跨檔一致性 / 技術準確性 / 結構性質疑）後留下的 limitation：

• Framework bias：5 篇 migration playbook 全落在 Type A / C / E、沒一篇 Type B / D / F。這反映 MySQL 領域 migration 的本質（多數情境是 schema 差 / operational 轉手 / paradigm shift）、也可能反映 6 type framework 的覆蓋限制
• Anti-recommendation 已補 overview 路由：本頁新增「Anti-recommendation 與升級路由」作為總入口；各 deep article 之後仍可逐篇補「何時維持簡單設計」段。
• Real case anchor 已下沉：本頁「真實案例 anchor」把 Shopify、Slack、GitHub gh-ost、YouTube / Vitess 與既有 09 case 串回 deep article；Shopify CDC、gh-ost workflow、YouTube / Vitess 與 Netflix Aurora consolidation 已補到對應 deep article 的 production case 段。
• PG 對比 narrative：對比段公允度尚可、但 PG 弱點（vacuum ops 開銷 / connection-per-process model / replication slot 治理）較少在 MySQL 視角展開、單方面對比偶有偏 MySQL 不利

案例對照

MySQL 沒有直接的 09 case（大規模 MySQL 多在 engineering blog、不在 vendor case study）、但作為 baseline / 遷移源 在多處出現：

真實案例 anchor

MySQL 真實案例的責任是把大規模 OLTP 的機制壓力放回正文。案例不只證明「某公司使用 MySQL」，而是提供 schema change、CDC、sharding、connection、queue 整合或 managed migration 的壓力來源。

案例下沉規則是先放 overview，再進 deep article。當某個案例只支撐服務定位，留在本頁；當案例提供具體操作訊號，例如 Shopify 的 Debezium connector scaling、GitHub 的 gh-ost workflow 或 YouTube 的 Vitess topology，對應 deep article 要保留 production case 段、讓讀者能從機制直接跳到案例。

常見陷阱

• 直接 ALTER TABLE 大表：lock 表 hours、production 停擺、必須用 online schema change
• 不用 GTID：replication topology 變更困難、recover from failure 容易出錯
• buffer pool 太小：cache miss 高、IOPS 飆升
• shard key 選錯：hot shard 出現、整體吞吐達不到名義
• connection 沒 pool：跟 PostgreSQL 同樣問題、用 ProxySQL
• semi-sync 對高吞吐 workload：每次 commit 等 ack、寫吞吐降一半

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：PostgreSQL vendor、Aurora vendor（managed MySQL）
• 操作：MySQL Hands-on（local lab、ProxySQL、OSC、replication failover、backup restore、Vitess sandbox）
• 上游：1.1 高併發資料存取、1.3 Transaction Boundary
• 下游：1.10 KV / Document DB 容量規劃（MySQL 不適用時的替代）
• 跨模組：9.5 瓶頸定位流程 — connection / replication / lock contention 常見 MySQL bottleneck
• 官方：MySQL Documentation、Vitess、PlanetScale

教學路線：Distributed SQL 與跨雲一致性

CockroachDB 服務頁的教學目標是把 PostgreSQL-like 介面背後的 range sharding、Raft replication、serializable transaction、leaseholder 與 region placement 說清楚。讀者讀完後要能判斷 distributed SQL 何時能取代自管 sharding，何時會把 latency 與 retry 壓力推回應用層。

定位：Spanner 的開源 / 跨雲替代

CockroachDB 跟 Spanner 解決同一個問題（跨 region 強一致 SQL）、但定位不同：

• Spanner：GCP managed service、用 TrueTime hardware
• CockroachDB：開源（雙授權）、可自管 + Cockroach Cloud、跨 AWS / GCP / Azure / on-prem、用 HLC + Raft

選 CockroachDB 的核心訴求：需要跨 region 強一致 SQL + 想避免雲商 lock-in、想自管或跨雲部署。

詳見 1.11 全球分散式 OLTP 的 CockroachDB 段。

容量特性

節點即容量單位：

• 跟 Spanner 同樣設計、節點數量決定容量
• 每節點承擔 query + storage + replication
• 線性擴展（理論）、實際依 query pattern

跨 region 配置：

• multi-region survival goal（zone-level / region-level）
• 跨 region quorum 必要、決定 latency
• 跟 Spanner 同樣的物理限制（跨洲 100ms+）

Replication：

• Raft consensus per range
• 預設 3-replica
• 可配置每個 region 不同 replica count（Survival Goals）

適用場景

1. 需要跨 region 強一致 SQL + 跨雲：

• multi-region active-active write
• GCP-only（Spanner）或 AWS-only（Aurora DSQL）和部署策略不合
• 對應 1.11 全球分散式 OLTP 的選型決策

2. PostgreSQL wire protocol 相容路徑：

• 既有 PostgreSQL 應用想升級到分散式
• 應用層改動小（保留 PostgreSQL driver / ORM）
• 注意：PostgreSQL 相容要以實際 query、extension 與 migration test 驗證

3. 自管 on-prem / hybrid：

• 金融 / 受監管產業需要 on-prem
• Spanner / Aurora DSQL 以 cloud service 為主
• CockroachDB 可自管

4. 想避免單一 vendor 全球分散式 lock-in：

• 開源 + 跨雲、可遷移性高
• 但企業版功能要付費（CockroachDB Cloud 或 Enterprise license）

不適用場景

1. single-region OLTP 夠用：

• 90% 場景 PostgreSQL / Aurora 已夠
• CockroachDB 有分散式 overhead（每個寫經 Raft）
• 替代：PostgreSQL、Aurora、MySQL

2. 極端高吞吐 single-query：

• CockroachDB 寫入有 Raft 開銷、單機吞吐 < PostgreSQL
• 整體吞吐靠 scale-out 達成、單一 query latency 較高

3. 跨洲低延遲（< 50ms）：

• 跟 Spanner 同樣物理限制
• 跨洲 quorum 100ms+ 是物理成本

4. 預算極敏感的小 workload：

• CockroachDB 至少 3 個節點（Raft quorum）
• 跟 single-instance PostgreSQL 比較貴

5. 需要 PostgreSQL 進階特性：

• 部分 PostgreSQL extension 或行為需要替代方案
• partial index、exclusion constraint 等可能缺

跟其他 vendor 的取捨

vs Spanner（GCP）：

• CockroachDB：開源、跨雲、可自管
• Spanner：GCP-only、TrueTime hardware、Google 規模驗證
• 選 CockroachDB：跨雲 / on-prem 需求
• 選 Spanner：GCP 生態 + managed operation + Google 規模驗證的成熟度

vs Aurora DSQL（AWS 2024）：

• CockroachDB：跨雲、生產驗證較久
• Aurora DSQL：AWS-only、serverless、新（2024）
• 選 CockroachDB：跨雲、想避免 AWS lock-in
• 選 Aurora DSQL：AWS 生態 + 已用 PostgreSQL + serverless 訴求

vs TiDB：

• CockroachDB：PostgreSQL wire、英語 / 歐美生態深
• TiDB：MySQL wire、亞洲生態深、HTAP（OLTP + OLAP 同庫）
• 選 CockroachDB：PostgreSQL 應用、跨雲
• 選 TiDB：MySQL 應用、需要 OLAP 整合、亞洲市場

vs PostgreSQL（傳統）：

• CockroachDB：分散式、跨 region 強一致
• PostgreSQL：single-primary、跨 region 是 async replication
• 選 CockroachDB：需要跨 region 強一致
• 選 PostgreSQL：single-region 夠用（90% 場景）

vs Aurora（single-region scaling）：

• CockroachDB：multi-region 強一致
• Aurora：single-region scaling、跨 region 是 async Global Database
• 選 CockroachDB：需要 multi-region write
• 選 Aurora：single-region scaling + AWS 生態

vs MySQL + Vitess（self-managed distributed MySQL）：

• CockroachDB：PostgreSQL wire、transparent sharding（range-based）、跨 region 強一致內建
• MySQL + Vitess：MySQL wire、application 層配 keyspace + shard key、跨 region 靠 application + async replication
• 選 CockroachDB：PostgreSQL 應用 + transparent multi-region + 想避開 Vitess operation burden
• 選 MySQL + Vitess：MySQL 應用 + 有 DBA 養 Vitess + 已是 YouTube / Slack 規模

容量規劃要點

1. Node count + zone / region 配置：

• 至少 3 個節點（Raft quorum）
• multi-region 通常 9+ 節點（3 region × 3 replica）
• Survival Goals 配置決定每 region 復原能力

2. Range（CockroachDB 的 partition）：

• 跟 DynamoDB partition、Spanner split 同類
• CockroachDB 自動 split 大 range
• application 主要管理 query locality、transaction retry 與 region placement

3. Locality 配置：

• 跟 Spanner 一樣可以指定 voting region
• 寫入 locality 影響跨 region latency

4. Backup / restore：

• CockroachDB 原生 backup 支援 cluster-level snapshot
• 增量 backup 支援
• 注意：incremental backup chain 可能很長、定期 full backup

5. Self-managed vs Cockroach Cloud：

• Self-managed：需要 ops team、可跨雲 / on-prem
• Cockroach Cloud：managed、跨 cloud（AWS / GCP / Azure）、可考慮 serverless tier

Deep article（已完成）

本批 deep article 覆蓋 CockroachDB 從 consensus 機制、multi-region 配置到 managed 形態選型的核心 production 議題：

DB4 cross-vendor entry：先看 aurora-dsql-spanner-decision-tree 識別 driver path、再進個別 vendor 深度。

multi-region-table-config 與 locality-aware-schema 切分：前者主寫「三種 table locality 怎麼選 + 選錯重配代價」、後者主寫「schema 怎麼配合 locality 設計（合規 boundary、跨州業務邏輯、Outposts 拓樸）」、兩者互補、survival goal 機制以 survival-goals 為 SSoT。

後續擴充（仍待補）

• PostgreSQL 相容性 audit（partial index / extension / SQL 行為 gap 清單）
• Backup / restore 與 PITR 操作（incremental chain 管理、restore 演練）
• Changefeed / CDC 配置（CockroachDB 原生 CDC 到 Kafka / sink）

「從 PostgreSQL 遷到 CockroachDB（playbook）」已由 PostgreSQL → CockroachDB migration 涵蓋、不再列為待補。

Anti-recommendation 與升級路由

CockroachDB 的 PostgreSQL-like 介面會降低導入門檻，但 distributed SQL 的成本會出現在 transaction retry、range lease、multi-region latency 與操作拓樸。這一段先說何時維持 PostgreSQL / Aurora，再說何時升級 CockroachDB、Cockroach Cloud、Spanner、Aurora DSQL 或 Vitess。

CockroachDB 的簡單路徑是先證明 distributed SQL 的價值大於 retry 與 latency 成本。若 workload 仍是 single-region OLTP，PostgreSQL / Aurora 通常提供更低成本；若跨 region 寫入與一致性是產品承諾，CockroachDB 才成為主要候選。

Transaction retry 的升級路徑要進入 application contract。Serializable default 能保護一致性，但 retry 會把 idempotency、timeout、user-visible latency 與 workflow compensation 帶回應用層；這些條件要在 migration playbook 前先盤點。

已知 limitation 與後續路由

CockroachDB overview 目前完成 distributed SQL 判斷。下一輪 deep article / playbook 應補 HLC + Raft、range / leaseholder、multi-region table locality、transaction retry pattern、PostgreSQL compatibility audit、Cockroach Cloud operation 與 PostgreSQL → CockroachDB migration。

案例對照

CockroachDB 在 09 案例庫已有三條直接 case 軸線（OLTP 寫入擴展、polyglot 補位、合規邊界），另外兩條對比參考軸線（Spanner 設計理念、受監管金融）一併保留。

Direct case（CockroachDB 為主角）

對比參考案例

CockroachDB direct case 的讀法是「寫入擴展（DoorDash）→ polyglot 補位（Netflix）→ 合規邊界（Hard Rock Digital）」三條軸線；對比案例則提醒讀者：Spanner 提供 global consistency 的成熟對照，受監管金融類案例提醒部署位置、合規邊界與自管能力常和一致性需求同時決定 vendor。

反向 sibling 路由

CockroachDB 的反向 sibling 路由用來把 PostgreSQL 相容性和 distributed SQL 責任拆開。若讀者從 PostgreSQL 章節過來，先讀 PostgreSQL → CockroachDB migration；若只是要 managed SQL 與 storage autoscale，先回 Aurora vendor；若要 Google Cloud 原生 external consistency 與 fully managed control plane，再對照 Spanner vendor。

這條路由的判準是「應用是否能承擔 distributed transaction 的語意差異」。SQL dialect 相近只降低 migration entry cost，真正的交付風險在 transaction retry、hot range、survival goal、backup restore 與 locality design。

常見陷阱

• single-region 用 CockroachDB：浪費分散式開銷、PostgreSQL 便宜很多
• 跨洲 active-active 期待低延遲：物理限制、跨洲 quorum 100ms+
• PostgreSQL extension 假設：部分 extension 或 SQL 行為需要替代方案，應用要驗證
• 不規劃 Survival Goals：default 配置可能不符合 RTO / RPO 需求
• backup chain 過長：incremental 不 full、recovery time 變長

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：Spanner vendor、Aurora vendor、PostgreSQL vendor
• 上游：1.11 全球分散式 OLTP — 完整選型對比
• 跨模組：9.6 容量規劃模型、9.12 SLO 與 Performance Budget
• Last reviewed：2026-05-22（PostgreSQL compatibility / survival goal / managed offering 屬時間敏感 claim）
• 官方：CockroachDB Documentation

教學路線：Managed SQL 與平台責任轉移

Aurora 服務頁的教學目標是把 PostgreSQL / MySQL 語意延伸到 AWS managed storage / compute 分離模型。讀者讀完後要能判斷哪些責任交給 Aurora，哪些責任仍留在 schema、query、maintenance window、region 與成本治理。

定位：storage / compute 分離的 SQL

Aurora 跟傳統 PostgreSQL / MySQL primary 最大差異是 storage layer 重寫。傳統 SQL primary 把 storage 跟 CPU / RAM 綁定、storage 擴容要換 instance、replication lag 受 compute 影響。Aurora 把 storage 拉到分散式 log service、跨 6 個 storage node（3 AZ × 2 node）、storage 跟 compute 獨立擴。

容量特性：

• 單一 cluster 最高 storage：128 TB
• 最多 15 個 read replica（單 region 內）
• read replica replication lag：10-30ms（vs 傳統 PostgreSQL 跨 AZ 可能秒級）
• 跨 AZ failover：< 30 秒（promote read replica）
• Aurora Global Database 跨 region replication：< 1 秒典型 lag

為什麼這個分離很重要：

• 傳統 PostgreSQL primary 上的 read replica 都靠 logical replication、會跟著 primary write load 走慢
• Aurora storage 直接複製到 6 個 storage node、read replica 從 storage 讀、不靠 primary
• → read replica 大幅減少 lag、可以撐更多 OLTP read traffic
• 對應 9.C23 Netflix +75% 效能改善的關鍵原因

適用場景

按公開 case 提煉的典型適用場景：

1. 既有 PostgreSQL / MySQL 應用想要 managed：

• wire protocol 相容，應用層改動通常集中在連線、參數與操作流程
• ORM / driver / SQL 多數可保留，但 migration plan 仍要驗證 dialect 與 extension
• 對應案例：9.C23 Netflix — 多套 RDBMS（PostgreSQL、MySQL、Oracle）統一到 Aurora、+75% 效能、-28% 成本

2. 金融交易 / 體育博彩 OLTP：

• 強 ACID transaction
• 多 read replica 處理 query traffic、不影響寫
• 對應案例：9.C4 DraftKings — 每分鐘 100 萬 ops、200 個獨立資料庫、Super Bowl 流量 +50% 無影響

3. 受監管產業跨市場部署：

• 每個市場一個獨立 cluster、合規分割
• 對應案例：9.C14 Standard Chartered — 7 個受監管市場、各自獨立 Aurora、總吞吐 4000 TPS、10x 提升

4. 高峰流量 + 多 read replica 擴容：

• read 高峰用 read replica 接、write 走 primary
• 對應案例：9.C28 FanDuel — 5-10x Super Bowl 峰值、直播 + 投注雙工作負載

5. Aurora Serverless v2 適用場景：

• 流量 unpredictable + sustained workload
• 自動 scale CPU / RAM，降低 instance class 管理負擔
• 適合：dev / test 環境、流量稀疏的多 tenant SaaS

6. Aurora Global Database：

• 跨 region async replication（< 1 秒 typical）
• DR + 跨地理 read（write 在 primary region、read 可從 secondary region）
• Global Database 是跨 region DR / read route，multi-region active-active write 要改看 Aurora DSQL

不適用場景

1. 跨雲需求：

• Aurora 是 AWS-only、wire protocol 相容但 storage 是 AWS 專屬
• 替代：自管 PostgreSQL / MySQL on Kubernetes

2. 需要最新 upstream PostgreSQL / MySQL 特性：

• Aurora 通常落後 upstream 1-2 個 major version
• 替代：RDS PostgreSQL（更接近 upstream）

3. 極端寫入吞吐：

• 單一 primary 寫入受 storage 設計限制（雖然比 PostgreSQL 快）

• 100K WPS 級別、考慮 sharding、CockroachDB、或 DynamoDB

• 對應 9.C29 Lemino — RDB connection limit 是 bottleneck、改 DynamoDB

4. 全球 multi-region active-active write：

• Aurora Global Database 是 async、有 lag，write 仍集中在 primary region
• 替代：Aurora DSQL（2024 推出）、Spanner、Cosmos DB

5. 預算敏感的小 workload：

• Aurora 比 self-managed PostgreSQL 貴 20-30%
• 小流量場景、自管 PostgreSQL on EC2 或 RDS 更便宜

跟其他 vendor 的取捨

vs RDS PostgreSQL / MySQL（同 AWS）：

• Aurora：storage / compute 分離、更多 read replica、更快 failover、跨 AZ 自動 replication
• RDS：純 managed PostgreSQL / MySQL、不重寫 storage、更接近 upstream
• 選 Aurora：需要 scale read replica 或 cross-AZ failover < 30 秒
• 選 RDS：需要最新 upstream 特性、預算更敏感

vs 自管 PostgreSQL / MySQL：

• Aurora：託管、自動 backup / failover，降低日常 database operation
• 自管：彈性高、可自己 tuning、跨雲可用、預算可控
• 選 Aurora：團隊想把 DBA / SRE 操作責任轉交 AWS、AWS 生態深
• 選自管：跨雲需求、需要客製化、預算極敏感

vs CockroachDB：

• Aurora：single-region scaling（一個 region 內擴）、AWS-only
• CockroachDB：multi-region 強一致、跨雲可用、PostgreSQL wire protocol
• 選 Aurora：AWS-only + single-region OLTP
• 選 CockroachDB：需要 multi-region 強一致 + 跨雲 / on-prem 彈性

vs Aurora DSQL（2024-12 preview / 2025-05 GA）：

• Aurora：single-region scaling、傳統 OLTP
• Aurora DSQL：multi-region active-active write、serverless、強一致
• 選 Aurora：流量集中在一個 region
• 選 Aurora DSQL：需要全球 active-active
• 從 PG / Aurora PG 遷 DSQL 的完整 playbook 見 PG → Aurora DSQL Migration

vs DynamoDB：

• 詳見 DynamoDB vendor page 對比段。Aurora 是 SQL、DynamoDB 是 KV、適用場景不同。

vs Azure SQL Hyperscale：

• 設計理念類似（storage / compute 分離）
• Aurora 在 AWS、Hyperscale 在 Azure
• 對應案例：9.C32 Clearent — Azure 生態的同類設計、5 億 payment txn / 年

容量規劃要點

從 09 案例庫提煉的 Aurora 容量規劃實踐：

1. read replica 是擴 read traffic 的主要工具：

• 最多 15 個 read replica、replication lag 10-30ms
• read replica autoscaler 按 CPU / connection 自動加減
• 對應 9.C4 DraftKings 用多個 read replica 處理「比賽期間用戶查 balance」流量

2. 200 個獨立 cluster 模式：

• Aurora 的實務設計通常用多個 bounded cluster 控制 blast radius
• 按業務切多個小 cluster（9.C4 DraftKings 200 個）、降低 blast radius
• 對應 microservice 私有 store（9.C23 Netflix 同樣思維）

3. Aurora I/O-Optimized：

• 2023-05 推出的 storage 配置
• 適合 I/O-heavy workload（write 多、scan 多）
• 比 standard storage 貴、但少 I/O 收費
• 對應 9.C4 DraftKings 用 I/O-Optimized 加速

4. Aurora Serverless v2：

• ACU（Aurora Capacity Unit）為單位、自動 scale 0.5-128 ACU
• 適合 dev / test、稀疏 workload、unpredictable burst
• 不適合：sustained predictable high workload（provisioned 便宜）

5. Cross-region Global Database：

• < 1 秒 typical replication lag、但是 async
• secondary region 可 read，write 仍回 primary region
• DR 切換通常 1-2 分鐘
• 對應 9.C14 Standard Chartered — 跨市場各自獨立 Aurora，合規邊界優先於 Global Database

6. Connection pool 仍是隱性限制：

• Aurora 跟傳統 PostgreSQL 一樣有 connection pool 上限
• 應用層 + Aurora 之間建議用 RDS Proxy 做 pool 共享
• 對應 9.C29 Lemino — RDB connection limit 是 surge 場景的 bottleneck；Lemino 案例發生在 RDS，但 connection-bound 機制同樣適用 Aurora

Deep article（已完成）

本 vendor 現有 deep article 覆蓋 Aurora 從 storage architecture、fleet 治理到容量彈性、連線管理與 distributed 升級門檻的核心 production 議題：

I/O-Optimized vs Standard 成本對比由 Aurora PostgreSQL I/O-Optimized Cost 主寫（storage I/O 成本模型 SSoT），本 vendor 各篇提到 storage 成本時 cross-link 它、不重複展開。

跨 vendor entry：先看 CockroachDB vs Aurora DSQL vs Spanner 決策樹（distributed SQL 三選一 + 撞牆訊號分型），再決定是否進 Aurora overview。

後續擴充（仍待補）

• Aurora Global Database write forwarding 深入
• Babelfish（SQL Server 相容層）適用判斷
• Blue/Green deployment 做 major version 升級
• Backup / PITR restore drill（hands-on lab）

Anti-recommendation 與升級路由

Aurora 的 managed SQL 能把大量操作責任交給 AWS，但它仍保留 single-primary SQL 的資料模型與交易邊界。這一段先說何時維持 RDS / Aurora，再說何時升級 Global Database、Serverless v2、RDS Proxy、Aurora DSQL 或 DynamoDB。

Aurora 的簡單路徑是先把 operation transfer 寫清楚。Backup、minor upgrade、storage growth、failover 與 read replica lag 交給平台後，schema design、query shape、transaction boundary、connection pool 與 cost guardrail 仍由 application / SRE 共同承擔。

Global Database 的升級路徑要先定義讀寫方向。它適合 DR 與跨地理 read，若業務需要多 region 同時寫入並保持強一致，應直接進入 Aurora DSQL、Spanner 或 CockroachDB 的 distributed SQL 比較。

已知 limitation 與後續路由

Aurora overview 目前完成 managed SQL 判斷。下一輪 deep article / playbook 應補 storage architecture、RDS Proxy、Global Database、Serverless v2、I/O-Optimized cost、PostgreSQL / MySQL → Aurora migration 與 Aurora → Aurora DSQL 的分歧路徑。

案例對照

Aurora case 的讀法是看 operation transfer 如何變成容量與成本結果。DraftKings 與 FanDuel 提供 peak OLTP 訊號，Standard Chartered 提供合規分區訊號，Netflix 則提供多套 RDBMS 整併到 managed SQL 的組織與成本訊號。

反向 sibling 路由

Aurora 的反向 sibling 路由用來避免把 managed SQL 誤讀成唯一升級方向。若讀者從 PostgreSQL / MySQL 章節過來，先對照 PostgreSQL → Aurora 與 MySQL → Aurora；若核心需求是 connection surge，補讀 DynamoDB vendor 與 Lemino case；若核心需求是 multi-region active-active write，轉到 Spanner vendor 或 CockroachDB vendor。

這條路由的判準是先問「保留 SQL + 轉移 operation」是否足夠。答案成立時，Aurora 是 RDS / 自管 MySQL / 自管 PostgreSQL 的 managed endpoint；答案需要改成 global quorum、partition-key access pattern 或 document API 時，Aurora 應退到對照組，而非成為最後選項。

常見陷阱

• 誤以為 Aurora 等於無限擴：寫吞吐仍受 primary 限制，容量曲線和 distributed SQL 不同
• 忽略 read replica：把所有 query 打 primary，會浪費 read replica scaling 能力
• 跨 region 強一致誤解：Global Database 是 async 複製，multi-region active-active 要看 Aurora DSQL / Spanner / CockroachDB
• connection pool 忽略：Aurora 仍是 PostgreSQL / MySQL、connection 上限有效
• 單一巨大 cluster：把所有業務塞進一個 cluster 會放大 blast radius，通常要按業務切

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：DynamoDB vendor page（NoSQL 對比）
• 上游：1.3 Transaction Boundary / 1.11 全球分散式 OLTP
• 下游：1.12 大規模 DB 遷移實戰（從 RDS / 自管遷到 Aurora）
• 跨模組：9.5 瓶頸定位流程、9.6 容量規劃模型
• Last reviewed：2026-05-22（Aurora storage / Serverless / Global Database / I/O-Optimized 屬時間敏感 claim）
• 官方：Amazon Aurora、Aurora storage architecture

教學路線：全球強一致與 TrueTime 成本

Spanner 服務頁的教學目標是把 global strong consistency、TrueTime、Paxos、region layout 與 processing unit 連成一條產品決策線。讀者讀完後要能判斷何時需要全球一致 SQL，並理解這種能力的 latency、成本與雲平台邊界。

定位：TrueTime + Paxos 的全球線性 SQL

Spanner 解決的是跨地理位置同時追求 strong consistency、linear scalability 與 global availability 的 OLTP 問題。

關鍵設計：

• TrueTime API：用 GPS + 原子鐘提供「全球 unambiguous 時間戳」、誤差 < 7ms
• External consistency（線性化）：跨節點交易順序跟 wall clock 一致
• Paxos-based replication：跨 zone / region quorum
• 線性擴展：2 nodes → 45K reads/sec、4 nodes → 90K reads/sec、依此類推

容量特性（引自 9.C10 Spanner 案例）：

• 內部峰值：> 10 億 requests / sec
• 線性擴展（不像 USL 系統會在某點 plateau）
• 跨 region quorum 延遲：50-200ms（視 region 距離）
• 最小容量單位：100 processing units（PU）≈ 1/10 node、適合小負載

適用場景

1. 金融交易、ticketing inventory、payment ledger：

• 需要強一致，避免 double-spend、oversell 或帳務順序錯亂
• 全球用戶但需要原子性
• 對應案例：9.C10 Spanner — Google Ads 計費與 Google Play 訂閱都需要把每次計費事件放進可驗證順序

2. 全球用戶的 OLTP（不只 read replica）：

• 跨 region 寫入、各地用戶寫入本地 region 仍維持全球強一致
• 它承擔的是 multi-region write path，而非 single primary + 跨 region read replica
• 對應案例：Blockchain.com（高頻 crypto 交易、強一致）

3. 想擺脫 sharding 複雜度：

• 傳統大規模 SQL 常走應用層 sharding（管 shard key、跨 shard query、resharding）
• Spanner 自動 partition，application 主要管理 schema、query shape 與 region layout
• 對應案例：9.C10 Spanner 案例 — 「節點數量是容量單位」，shard placement 由 Spanner 管理

4. PostgreSQL 相容路徑：

• 2024 後 Spanner 提供 PostgreSQL dialect interface
• 從 PostgreSQL 應用遷入 Spanner 變得容易
• 跟 CockroachDB / Aurora DSQL 類似的策略

不適用場景

1. 跨洲低延遲（< 50ms）需求：

• 跨洲 quorum 物理上 100ms+ 不可壓縮
• 替代：single-region OLTP（Aurora、Cloud SQL）+ eventual consistency 跨 region 同步

2. 高 throughput 但容忍 eventual consistency：

• Spanner 強一致有溢價，eventual consistency workload 通常有更低成本選項
• 替代：Bigtable（wide-column、eventual）、DynamoDB Global Tables（KV、eventual）

3. 小規模 OLTP：

• 100 PU 起跳、月費約 $65 起、比 Cloud SQL 貴
• 流量 < 1000 RPS 的場景、Cloud SQL 更划算
• Spanner 主要對 中大規模 + 全球 workload

4. 跨雲需求：

• Spanner 是 GCP managed service，cross-cloud / on-prem 需求要看 CockroachDB、TiDB 或其他自管路線
• 替代：CockroachDB、TiDB（自管、可跨雲）

5. 需要 OLAP 分析能力：

• Spanner 定位在 OLTP，analytics workload 交給 BigQuery 或其他 OLAP 系統
• 替代：跟 BigQuery 整合做 ETL、或用 Spanner Graph（2024 推出）

跟其他 vendor 的取捨

vs Aurora DSQL（AWS 2024 推出、概念對標 Spanner）：

• Spanner：用 TrueTime hardware、生產驗證 17 年（Google 內部）+ 7 年（公開）
• Aurora DSQL：新（2024）、PostgreSQL 相容、serverless
• 選 Spanner：GCP 生態、需要極致成熟度
• 選 Aurora DSQL：AWS 生態、需要 PostgreSQL ORM 相容

vs CockroachDB：

• Spanner：managed、TrueTime hardware、GCP 限定
• CockroachDB：自管、HLC + Raft（不靠 TrueTime）、跨雲
• 選 Spanner：想把 operation 交給 GCP managed service，並需要 Google 規模驗證
• 選 CockroachDB：跨雲 / on-prem、PostgreSQL 相容、自管彈性

vs TiDB：

• Spanner：GCP-only、PostgreSQL-like
• TiDB：可自管 + Cloud、MySQL 相容、中國 / 亞洲生態深
• 選 Spanner：英語 / 歐美生態
• 選 TiDB：MySQL 應用、亞洲市場

vs Aurora（traditional single-region scaling）：

• Spanner：全球分散式
• Aurora：single-region scaling
• 選 Spanner：流量明確跨 region + 需要強一致
• 選 Aurora：流量集中一個 region（多數情況）

vs Cosmos DB（multi-region write）：

• Spanner：strong consistency 跨 region
• Cosmos DB：5 個 consistency levels、AP 系統（含 strong 但語義不同）
• 選 Spanner：需要 linearizable（金融、ticketing）
• 選 Cosmos DB：可接受 session / eventual、Azure 生態、需要 multi-model

vs Bigtable：

• Spanner：SQL、強一致、OLTP
• Bigtable：wide-column、eventual replication、時序 / IoT / 大資料
• 兩者互補：Bigtable 承擔大資料 / wide-column，Spanner 承擔強一致 OLTP

vs PostgreSQL（baseline）：

• PostgreSQL：single-primary、跨 region async replication、90% 場景夠用
• Spanner：全球線性化、強一致跨 region、需要 GCP + 接受 latency / 成本
• 從 PostgreSQL 升級 Spanner 的判準：流量明確跨 region，且跨 region 一致性是 product requirement
• 詳見 PostgreSQL vendor page 取捨段 + 1.11 全球分散式 OLTP

容量規劃要點

從 09 案例庫 + Spanner 文件提煉：

1. 節點數量 = 容量單位：

• 節點配置通常用較長週期 review，並在事件高峰前預先調整
• 線性擴展讓 forecast 簡單（2x 流量 → 2x 節點）
• 對應 9.6 容量規劃模型 的「不可水平擴容服務」反向 — Spanner 是 可水平擴容 但需要 提前 provision

2. 跨 region quorum 配置：

• multi-region instance 可選擇哪些 region 是 voting member
• voting region 數量決定 failure domain
• 跨大洲 voting 延遲高、跨大陸內可接受

3. 100 PU 起跳的 granular sizing：

• 早期 Spanner 最小單位 1 node（約 $1000+/month）、中小負載難用
• 後來推出 100 PU（1/10 node、約 $65/month）、讓小負載也能 evaluate

4. 跨環境與新產品能力要查官方文件：

• Spanner 的跨環境、graph、PostgreSQL dialect 與 change streams 能力持續演進
• 實作前要用官方文件確認可用 region、版本、限制與 pricing

5. TrueTime 是 Spanner 價值之一：

• Spanner 還有 schema migration without downtime、change streams、interleaved tables
• 評估 Spanner 要同時看跨 region 強一致與整體 SQL 工程能力

Deep article（已完成）

本批 4 篇 deep article 已完成、覆蓋 Spanner 從 TrueTime 到 Cloud SQL 遷移的核心 production 議題：

DB4 cross-vendor entry：先看 CockroachDB / Aurora DSQL / Spanner 決策樹 識別 driver path、再進本 vendor 深度。

後續擴充（仍待補）

• Spanner Graph 進階查詢 lab（GQL pattern、super node 處理、遍歷效能調校）
• Data Boost 容量規劃與成本模型 deep dive
• Change Streams → Dataflow hands-on lab（建 stream、部署 pipeline、驗證 end-to-end）
• Spanner regional → multi-region topology 升級 playbook

Anti-recommendation 與升級路由

Spanner 的 global strong consistency 是高價值能力，也會把 latency、region layout 與 GCP lock-in 帶進核心架構。這一段先說何時維持 Cloud SQL / Aurora，再說何時升級 Spanner、CockroachDB、Aurora DSQL 或 Bigtable / DynamoDB。

Spanner 的簡單路徑是先證明跨 region 一致性是產品需求。若只是想要全球 read latency，read replica、cache、edge KV 或 eventual consistency pipeline 可能更划算；Spanner 適合把「全球寫入順序正確」視為產品承諾的資料。

Region layout 的升級路徑要先定義 leader、voting replica 與使用者地理分布。跨洲 quorum 會把物理延遲放進 transaction path，因此 latency budget、降級策略與 read staleness policy 要一起寫進設計。

已知 limitation 與後續路由

Spanner overview 目前完成 global SQL 判斷。下一輪 deep article / playbook 應補 TrueTime、external consistency、PostgreSQL dialect、interleaved tables、change streams、Cloud SQL / PostgreSQL → Spanner migration 與 Spanner / BigQuery federation。

案例對照

Spanner case 的讀法是先看一致性需求，再看容量數字。10 億 req/sec 證明它能水平擴展，但讀者真正要回收的是「計費、訂閱、庫存、交易順序」這類需要 global external consistency 的產品壓力。

反向 sibling 路由

Spanner 的反向 sibling 路由用來把 global strong consistency 和雲端代管責任一起判讀。若讀者從 PostgreSQL / MySQL 過來，先確認是否具產品契約等級的 external consistency 需求；若只是 managed SQL 與 replica scaling，回 Aurora vendor；若要 PostgreSQL-like distributed SQL 且需要自管或多雲彈性，對照 CockroachDB vendor；若 access pattern 是固定 KV / document，先看 DynamoDB vendor 或 Cosmos DB vendor。

這條路由的判準是交易順序是否跨 region 影響產品正確性。Spanner 的價值在 external consistency、schema 與 SQL 能力、全球 deployment 與 Google Cloud operation model 的組合；若產品只需要 eventual / session consistency，較輕的 NoSQL 或 managed SQL 常有更低成本。

常見陷阱

• 誤以為跨 region 強一致沒有延遲代價：跨洲 quorum 100-200ms 是物理成本
• 設計 schema 像傳統 PostgreSQL：Spanner 有 interleaved tables、適當用能加速查詢
• 所有讀取都用強一致：read-only transaction 可選 bounded staleness，reporting 類路徑常能用 stale read 換較低成本
• 單 region 用 Spanner：浪費、Cloud SQL / Aurora 更便宜
• 不評估 100 PU 起跳：早年 1 node minimum、現在 100 PU 起、small workload 也可以 POC

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：Aurora vendor、DynamoDB vendor、CockroachDB vendor
• 上游：1.11 全球分散式 OLTP
• 跨模組：9.6 容量規劃模型 — 全球 OLTP 的容量規劃特殊性
• Last reviewed：2026-05-22（processing units / PostgreSQL interface / TrueTime 文件屬時間敏感 claim）
• 官方：Cloud Spanner、TrueTime: Time Distributed in Spanner

本文承接 終端機圖形化工具總覽 的資料庫客戶端分類。工具分兩種範式：全螢幕 TUI 客戶端，與增強型 REPL。

兩種範式：全螢幕 TUI 與增強型 REPL

全螢幕 TUI（harlequin / lazysql）把 schema 樹、查詢編輯器、結果表格排進多個面板，像縮小版的 DBeaver。增強型 REPL（pgcli / litecli）仍是一行一行打 SQL，但加上語法高亮、智能補全與表格化輸出，是 psql / mysql 原生 client 的升級版。

選哪種看工作型態：要邊看 schema 邊探索資料，用全螢幕 TUI；要快速接上跑幾條查詢、或塞進腳本，用 REPL。

全螢幕 TUI：IDE 風與瀏覽器風

兩個全螢幕 TUI 的互動模型剛好相反，這是選型最該先分清的一點。

harlequin 是 SQL IDE 風：左側 Data Catalog 樹列出 db → schema → table → 欄位（帶型別標記，整數 #、字串 s、numeric #.#），中間是查詢編輯器，寫好 SQL 按 Ctrl+Enter 執行、結果在下方表格。點表只是把表的限定名稱插進編輯器、輔助組查詢，不會自動顯示資料。它用 Python（Textual）寫，adapter 涵蓋 postgres、mysql、sqlite、duckdb、odbc，預設 adapter 是 duckdb，連別的 DB 用 -a 指定，例如 harlequin -a postgres "<連線字串>" 或 harlequin -a sqlite db.sqlite。

lazysql 是瀏覽器風：左側選一個表，右邊直接顯示該表記錄、不必寫 SELECT。上方分頁切 Records / Columns / Constraints / Foreign Keys / Indexes（[ 與 ] 切換）。篩選按 / 開 WHERE 輸入，帶運算子補全（=、≠、>、between、ilike、in、like、regexp 等），只寫條件、不用整句。要跑自訂 SQL 按 Ctrl+E 開編輯器（vim modal、有 -- INSERT -- 模式）寫完整語句、Ctrl+R 執行。它用 Go 寫、lazygit 風的鍵盤導航。

判讀：習慣先寫 query 再看結果的選 harlequin；習慣點開表瀏覽、偶爾才下複雜 SQL 的選 lazysql。

dblab（Go）與 rainfrog（Rust）是另外兩個實機驗證過的瀏覽風 TUI。dblab 走混合型：左側樹（Ctrl+H 聚焦、j/k 移動、Enter 看表的列）配上方查詢編輯器（Ctrl+E 執行），瀏覽與寫 query 兩條路都有。它有一個實測 gotcha：編輯器的查詢要 schema 限定（SELECT * FROM public.products 才行、裸 products 會報 relation 不存在），因為編輯器連線的 search_path 沒含 public，而樹瀏覽（Enter）不受這點影響。rainfrog 專注 Postgres：側欄選表看 rows / columns / constraints / indexes / rls policies，查詢編輯器是 vim modal（i 進 insert、v 進 visual），另有 history 與 favorites 分頁。實測它不支援滑鼠操作，面板與分頁一律用 Tab 切換、其餘靠鍵盤導航。

增強型 REPL：dbcli 家族

pgcli（Postgres）、mycli（MySQL）、litecli（SQLite）是同一個專案（dbcli）的三個 client，把原生 psql / mysql / sqlite3 補上智能補全（表名、欄位、關鍵字）、語法高亮與對齊的表格化輸出。手感仍是 REPL，但打 SQL 時會即時提示。

它們也能非互動執行、適合腳本：litecli 用 -e（litecli db.sqlite -e "SELECT ..."），pgcli 在 stdin 非 TTY 時讀管線（echo "SELECT ..." | pgcli "<連線字串>"），輸出是對齊的 ASCII 表格。要在腳本裡取一次查詢結果、又想要比 psql -c 更好的排版時，這條路最直接。

usql 走另一條路：universal CLI，一個工具用統一介面連 Postgres、MySQL、SQLite 等各種 DB，連線字串以 scheme 區分（postgres://...、sqlite:...），也支援 -c 非互動執行。它不是 TUI，行為像能連多種 DB 的加強版 psql。一台機器要連好幾種不同 DB 時，一個 usql 比每種 DB 各裝一個 client 省事。

遠端連線的一個 gotcha：SSL 模式因 driver 而異

同一個 Postgres、同一條連線字串，不同 client 的 SSL 預設不一樣。lazysql 走 Go 的 pq driver、預設要求 SSL，連沒開 SSL 的 DB 會報 pq: SSL is not enabled on the server，要在連線字串加 ?sslmode=disable：postgresql://user:pass@host:5432/db?sslmode=disable。pgcli 與 harlequin 走 Python 的 psycopg、預設行為不同，同樣的 DB 不加也能連。遠端連不上、又確定帳密與 port 對的時候，先查的就是 sslmode。

同類其他選擇

同範式還有 gobang（Rust）。它未上 crates.io、Homebrew 也沒有對應 formula，本機未能安裝，列出供參考、未實機驗證。

下一步路由

• 把 DB client 擺進可持久化的多工器 pane：tmux 基礎。
• 編譯型工具（lazysql / dblab / rainfrog）搬到遠端的單一 binary 注意事項：git 線圖工具選型。
• SQL 客戶端在遠端工具分類中的定位：終端機圖形化工具總覽。

本文的判讀錨點是：SQLite 測過代表某個 repository contract 在 SQLite 語意下成立。當 production target 是 PostgreSQL、MySQL、D1、Turso 或其他 server database 時，測試與 migration 要補上 dialect gap evidence。

Type Affinity

Type affinity 的核心責任是定義資料寫入時如何被保存與比較。SQLite 官方 Datatypes 文件說明 SQLite 使用 dynamic typing，型別關聯在 value 層與 column affinity 層共同作用；STRICT tables 則提供較嚴格的型別檢查。

Type affinity 的教學重點是把資料合約放在 application boundary。若 domain 說 created_at 是 timestamp，就要定義 storage format、timezone、precision、comparison query 與 serialization，而非只讓 SQLite 接受任意 value。

1CREATE TABLE orders (
2  id INTEGER PRIMARY KEY,
3  created_at TEXT NOT NULL,
4  total_cents INTEGER NOT NULL CHECK (total_cents >= 0)
5) STRICT;

這段 schema 用 STRICT、NOT NULL 與 CHECK 讓 fixture 更接近正式資料合約。Production target 仍要跑 PostgreSQL / MySQL container test，確認 timestamp、integer range 與 constraint error mapping。

Constraint Behavior

Constraint behavior 的核心責任是確保資料完整性由 database 和 application 共同維護。SQLite 支援 primary key、unique、check、foreign key 與 deferred constraint，但 foreign key enforcement 需要明確啟用，migration / test runner 也要確認連線設定。

Foreign key 是 SQLite fixture 最常漏掉的設定。每個測試連線開啟後應立刻查 PRAGMA foreign_keys;，並用一個故意違反 FK 的 fixture case 確認錯誤會出現。

1PRAGMA foreign_keys = ON;
2SELECT foreign_keys FROM pragma_foreign_keys;

Constraint error 要在 repository adapter 層被歸類。若 production target 會把 duplicate key、foreign key、check violation 映射成不同 error code，SQLite fixture 也要至少保留 domain-level classification test。

Transaction Behavior

Transaction behavior 的核心責任是定義讀寫隔離、savepoint、nested workflow 與 retry。SQLite 官方 isolation 文件說明 connection 之間的隔離語意；WAL mode 下 reader / writer behavior 也會影響 concurrent test。

Savepoint 可以讓 application 實作可組合的 transaction helper。若上層 workflow 已在 transaction 內，內層 repository 可以使用 savepoint 承接局部 rollback，而非開另一個 database transaction。

1SAVEPOINT create_order;
2INSERT INTO orders(id, created_at, total_cents) VALUES (1, '2026-05-21T00:00:00Z', 1200);
3RELEASE create_order;

Busy timeout 是測試穩定性的關鍵設定。若 fixture 會平行跑測試，應每個 temp DB 獨立，或在專門 concurrency lab 裡測 SQLITE_BUSY；一般 contract test 要追求 deterministic result。

Index Model

Index model 的核心責任是把查詢形狀與資料量變成可觀測的計畫。SQLite 支援 B-tree index、covering index、partial index、expression index 與 query planner；但 planner choice、統計資訊與 function support 會和 target DB 不同。

Index review 要從 query pattern 開始，而非從「常用欄位」開始。SQLite 可以用 EXPLAIN QUERY PLAN 檢查是否掃 index；production target 要用自己的 explain 工具重跑。

1EXPLAIN QUERY PLAN
2SELECT id, total_cents
3FROM orders
4WHERE created_at >= '2026-05-01T00:00:00Z'
5ORDER BY created_at DESC
6LIMIT 50;

Index drift 是 migration 的常見風險。SQLite fixture 裡的 index 可以讓測試變快，但若 production schema 缺少同等 index，正式服務會在資料量成長後出現 latency spike；因此 index 要進入 schema diff audit。

Dialect Gap

Dialect gap 的核心責任是把 SQLite 與 target database 的差異寫成 matrix。這份 matrix 應跟 repository adapter、migration plan 與 CI test suite 綁定。

Dialect matrix 要以 query contract 為單位。每個 repository method 至少列出 SQL feature、SQLite behavior、production behavior、test layer 與 fallback strategy。

1Contract: Search active documents by tenant and prefix
2SQLite: FTS5 virtual table in fixture
3PostgreSQL: tsvector + GIN index
4Risk: ranking / tokenizer / collation differ
5Evidence: golden result set + production container explain

這種寫法讓測試負責驗證 domain contract，避免把兩個 SQL engine 的搜尋語意視為完全一致。

Test / Migration Impact

Test / migration impact 的核心責任是決定哪些東西可以用 SQLite 快速驗證，哪些東西要交給 production-like database。SQLite 很適合 repository contract、migration fixture、local development 與 file lifecycle drill；涉及 planner、extension、collation、locking、permission、role 與 HA 時，需要追加 target DB evidence。

SQLite fixture 的價值在於快、穩、便宜。它應承擔「資料合約是否被 repository 保護」；production container 或 staging database 承擔「正式 engine 是否用同樣方式執行」。

下一步路由

SQL dialect and index limits 完成後，下一步要把 gap 接到實作層。測試設計讀 Test Fixture Best Practice；migration 實作讀 Schema migration / versioning；要升級到 PostgreSQL，讀 SQLite to PostgreSQL migration。