Tarragon

"Database"

• 2026-06-26 部署順序與資料庫上 IaC 核心服務的依賴圖決定部署順序，資料庫作為第一批上層服務需要最謹慎的 IaC 描述 — 涵蓋 RDS 接線、連線管理、read replica 與端點暴露
• 2026-05-27 DB3 Vendor Selection：document / KV / multi-model 三方選型 + workload shape 前置判讀 MongoDB / DynamoDB / Cosmos DB 三家 NoSQL 選型 entry point：workload shape × access pattern × consistency 三軸前置判讀、migration path 三型、federated DB 視角、三 vendor 對比 10 軸
• 2026-05-13 1.1 高併發下的 SQL 讀寫邊界 說明高併發服務如何共用資料庫 client、控制 transaction、管理 connection pool、避免資料庫成為瓶頸
• 2026-05-13 1.2 Schema Design 與資料建模 整理 table、index、key、partition、denormalization 與命名規則
• 2026-05-13 1.3 Transaction 與一致性邊界 交易邊界、isolation level、retry 策略、distributed transaction（2PC、Saga）與跨 region 強一致取捨
• 2026-06-26 資料庫大版本升級 MySQL 5.7→8.0、PostgreSQL 13→16 等大版本升級的相容性評估、備份保險、平行驗證、切換策略與升級後監控
• 2026-05-13 1.4 Repository Adapter 實作 Port / Adapter 邊界、row mapping、error translation、ORM vs query builder 選型、contract test 設計
• 2026-05-13 1.5 攻擊者視角（紅隊）：資料層弱點判讀 從資料存取邊界、外洩路徑與修復代價、盤點 database 的主要弱點
• 2026-05-13 1.6 資料庫轉換實作：雙寫、回填、切流與回滾 同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工
• 2026-05-11 1.7 Schema Migration Rollout 證據（Schema Migration Rollout Evidence）實作示範 以訂單付款狀態欄位演進示範 schema migration 如何產出 evidence、release gate 與 incident decision log。
• 2026-05-13 1.8 State Ownership 與 Query Boundary 正式狀態 vs 派生狀態的責任分層、CQRS / event sourcing / materialized view、四種 query 邊界
• 2026-05-13 1.9 Reconciliation 與 Data Repair 資料不一致的分類、偵測模式、修復策略、audit trail、跟 backup / PITR 整合
• 2026-06-26 無 SSH 環境的資料庫備份與變更管理 在只有 phpMyAdmin 或有限遠端連線的無 SSH 環境裡，怎麼建立可靠的資料庫備份策略、schema 變更紀律與還原演練流程
• 2026-05-13 1.10 KV / Document DB 容量規劃 DynamoDB / Cosmos DB / Bigtable / MongoDB 等 KV / Document DB 的容量設計、partition key 取捨、capacity mode 選擇
• 2026-06-16 從 Firestore 遷往自建 relational：撞牆驅動的 Type E 重建模、存取模型反轉與並行期 Firestore → 自建後端 + relational 不是匯資料而是反轉存取模型：client 直連變 API 中介、Security Rules 授權變後端授權、document 反正規化變正規 schema、realtime listener 與 offline 同步要重建；本文走 Type E paradigm shift 結構、展開為何字面遷移不成立、哪些該遷哪些先留、dual-write + shadow read 階段化與遷出代價判讀
• 2026-05-19 DynamoDB Strongly Consistent → Eventually Consistent：same protocol, different contract DynamoDB consistency model 從 strongly consistent read 改 eventually consistent read 是 50% cost 優化但風險集中在 application contract — 同 vendor / 同 protocol / 同 table / 不同 read consistency；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 提出的 consistency axis 候選；涵蓋 read pattern audit / 5 個 production 踩雷
• 2026-05-19 MongoDB → Atlas：Atlas 不是 MongoDB + managed、是另一個 product Atlas 號稱「MongoDB managed」但 operational model 完全不同（auto-scaling / VPC peering / IAM-driven access / 內建 backup / billing 模型）；本文採用 Type C operational redesign hybrid 結構、4-phase operational migration + drop-in cutover、5 個 production 踩雷（連線數限制 / IP whitelist / backup retention / IAM token 過期 / billing 暴漲）
• 2026-05-19 MySQL → PostgreSQL：從 SQL dialect diff 跑出來的 Type A 6-phase migration MySQL → PostgreSQL 是 Type A 高 schema 差 migration 的標準形態 — SQL dialect / collation / case sensitivity / replication 模型差異主導；用 pgloader / AWS DMS / 自管 dual-write 三條 path、5 個 production 踩雷（auto_increment vs SERIAL / charset 跟 collation / case sensitivity / index syntax / triggers）
• 2026-05-18 PostgreSQL Patroni HA：從 leader 失聯到 client 重連的 5 段 failover lifecycle Patroni 把 PostgreSQL HA 拆成 detection / election / promotion / reconfiguration / recovery 五段 lifecycle、每段都有獨立配置跟 failure mode；DCS quorum + watchdog 防 split-brain、async/sync replication 取捨、5 個 production 踩雷、跟 PgBouncer / HAProxy / cert-manager 整合
• 2026-05-13 1.11 全球分散式 OLTP Spanner / Aurora DSQL / Cosmos DB multi-region write / CockroachDB / TiDB 的全球一致性取捨
• 2026-06-16 Firestore Security Rules 授權建模與可測試化：把規則當程式碼治理 Firestore client 直連模型把整個授權控制面壓在 Security Rules 這套 DSL 裡；本文展開規則的求值模型、把授權拆成可組合 function、用 emulator 寫單元測試、五個把規則寫成資安漏洞的 production 踩坑，以及規則複雜度撞牆時把授權拉回後端的邊界
• 2026-05-19 MongoDB Shard Expansion + Multi-DC：Type F「不需要 parallel run」的 multi-region 例外 MongoDB sharded cluster 加 shard + 跨 DC expansion 是 Type F「topology re-layout」第 3 個 dogfood — 同時改 sharding + replication topology + region distribution；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 第 3 點「Type F 不需要 parallel run」claim 的例外（multi-region rollout 必須 parallel run + 切流量）；涵蓋 chunk migration / replica set add member / cross-DC routing
• 2026-05-19 MySQL Replication Topology：async / semi-sync / GTID 不是三選一、是三個 trade-off 軸的疊加 MySQL replication 不是「選 async 還是 semi-sync」、是 *durability / latency / consistency* 三個 trade-off 軸的疊加；GTID 是跨 mode 的 infrastructure layer、不是第三種 mode。本文走 3 軸取捨模型 → async / semi-sync 行為對比 → GTID 替代 binlog-position 的好處 → 配置 step-by-step → 5 production 踩雷（lag 暴衝 / semi-sync 退回 async / GTID gap / Loss-Less semi-sync 真的 loss-less / chained replication 雪崩）→ 跟 Aurora MySQL / Vitess / ProxySQL / Orchestrator 整合
• 2026-05-19 PostgreSQL Replication Topology：async / sync / quorum 三模式跟 LSN + replication slot 的三軸組合 PostgreSQL streaming replication 不是「sync 或 async」、是 *durability / latency / consistency* 三軸組合 + LSN-based 進度追蹤 + replication slot 治理。本文走 3 軸取捨模型、async / sync / quorum-based sync 行為對比、LSN + replication slot 機制、配置 step-by-step、5 production 踩雷（standby lag 暴衝 / sync standby 退回 async / orphan replication slot / cascading replication 雪崩 / failover 後 timeline 分歧）、跟 Patroni HA + logical replication 整合
• 2026-05-13 1.12 大規模 DB 遷移實戰 跨 DB 遷移的 dual-write、[shadow read](/backend/knowledge-cards/shadow-read/)、cutover、rollback 流程 — 從實戰案例提煉的工程做法
• 2026-06-16 Firestore 高頻寫入與 distributed counter：單 document contention 邊界與分片計數 Firestore 單一 document 有持續寫入的軟上限、高頻計數寫爆 contention 是常見事故；本文展開寫入 contention 的成因、distributed counter 分片計數的實作與讀取彙總、shard 數量與讀寫成本的取捨、五個高頻寫入踩坑，以及計數需求超過分片能處理時改走外部聚合的邊界
• 2026-05-27 1.13 應用層查詢反模式與 Query 預算 整理 N+1、select *、缺索引、ORM lazy load、long transaction 等查詢反模式與每請求的 query 預算判讀
• 2026-05-19 MySQL Online Schema Change：gh-ost 跟 pt-online-schema-change 兩條完全不同的 ghost table 路徑 MySQL ALTER TABLE 可能鎖整張表，production 需要 online schema change 流程。gh-ost（GitHub）跟 pt-online-schema-change（Percona）都用 ghost table 解決、但底層機制完全不同：pt-osc 用 trigger 同步、gh-ost 用 binlog stream 同步。本文走兩工具機制對照表 → trigger vs binlog 各自取捨 → 配置 step-by-step → 5 production 踩雷（trigger overhead / binlog 延遲 / FK constraint / hot trigger lock / 切換瞬間 deadlock）→ 何時用哪一個
• 2026-05-19 PostgreSQL Online Schema Change：先用 ALTER 內建特性、不能解才 pg_repack / pg-osc PostgreSQL ALTER TABLE 對多數變更已是 *fast catalog-only*（add column nullable / drop column / 改 default），不必走 ghost table tool。本文走 PG 內建 fast DDL 行為、何時必須走 pg_repack / pg-osc、兩工具機制對比（trigger-based vs WAL-shipping）、配置 step-by-step、5 production 踩雷（lock 升級 / VACUUM FULL 誤用 / pg_repack version mismatch / concurrent index 失敗清理 / generated stored column 不能 online）、跟 MySQL gh-ost / pt-osc sibling 對比
• 2026-06-16 Firestore document 反正規化與一致性維護：fan-out write、副本同步與資料修復 Firestore 沒有 JOIN，查詢能力逼著把關聯資料反正規化複製多份；本文展開反正規化的建模決策、fan-out write 維護副本一致、batch 與 transaction 的選擇、五個副本不一致的 production 踩坑，以及反正規化複雜到該回關聯式的邊界
• 2026-05-27 1.14 Production Slow Log Closed Loop 把 production slow log 從『偶爾看一下』變成『定期審視 + PR review 整合 + regression 偵測』的閉環、補 1.13 反模式清單後的操作層
• 2026-05-19 MySQL ProxySQL 配置：connection / query / route / response 四段 lifecycle 跟 query rule 設計 ProxySQL 是 MySQL 生態的 connection pool + query routing 標準。本文走 connection → query parse → route → response 四段 lifecycle、query rule engine 的 rule chain 設計、Hostgroup / Server / User 三層 schema、配置 step-by-step（讀寫分離 + replica lag-aware routing）、5 production 踩雷（query rule 順序錯亂 / connection 漂移 / write 路由到 replica / runtime / disk schema drift / mirror traffic 副作用）、跟 Replication / Orchestrator / HAProxy 整合
• 2026-05-19 PostgreSQL Connection Scaling：process-per-connection model 跟為什麼 pooler 是必裝 PG 每個 client connection fork 一個 backend process（不是 thread）、RAM 成本 5-15MB/connection、context switch 跟 fork() cost 在 100+ connection 後線性放大、所以 pooler 不是 *optional optimization* 而是 *production prerequisite*。本文走 process-per-connection model 跟 MySQL thread-per-connection 對比、max_connections + shared_buffers + work_mem 三 GUC 互動、application-side pool vs middleware pool vs RDS Proxy 三層選擇、5 production 踩雷（connection storm / fork() cost 在 burst 流量 / shared_buffers 跟 connection 數壓縮 / double-pool 配置錯誤 / max_connections 設太大反而慢）、跟 PgBouncer config 互補不重複
• 2026-06-16 Firestore realtime listener 扇出與成本：snapshot 訂閱、re-read 計費與連線規模 Firestore 的 snapshot listener 提供即時同步、但訂閱的扇出、查詢結果變動的 re-read 計費與連線數會在規模下變成成本與效能瓶頸；本文展開 listener 的推送模型、訂閱範圍設計、五個 realtime 成本踩坑，以及即時需求超過 listener 該換推送架構的邊界
• 2026-05-19 MySQL Orchestrator Failover：HA 工具自己怎麼 HA？raft cluster + GTID-based promotion 的兩段 paradox Orchestrator 是 MySQL HA 自動 failover 的 de facto standard、但讀者第一個問題往往是「HA 工具自己會壞嗎」。本文走 Orchestrator 的雙層架構（管 MySQL 的 raft cluster + 被 raft 管的 orchestrator instance）→ topology discovery → failure detection → failover decision tree → promote action → 5 production 踩雷（split-brain 跟 fencing / pre-failover hook 失敗 / anti-flapping window / GTID errant transaction / VIP 跟 ProxySQL 整合斷層）→ 跟 ProxySQL / Patroni / RDS 對比
• 2026-05-19 PostgreSQL Index Selection：B-tree / GIN / GiST / BRIN / Hash 對應 workload 的決策樹 PG 有 6 種 index method（B-tree / Hash / GIN / GiST / SP-GiST / BRIN）跟 partial / expression / covering 三種變體、不是「都用 B-tree 就好」。每種 index 有自己的 query pattern、儲存代價、write amplification 跟 maintenance 成本。本文走 6 種 index 的適用 workload 對照、決策樹、partial / expression / covering / multi-column 變體、5 production 踩雷（過度 index / partial 條件不對 / B-tree 對 JSON 無效 / BRIN 對非 correlated 資料無效 / multi-column 順序錯）、跟 query-optimization 的 EXPLAIN 互補
• 2026-05-19 MySQL InnoDB Tuning：為什麼一個 100 GB DB 在 64 GB RAM server 上 query 慢 5 倍 InnoDB 是 MySQL 預設 storage engine、預設值給 256 MB buffer pool（早期 default）。本文從一個常見痛點開場（DB > RAM 但 server 仍 swap）、走 4 個 critical knob（buffer pool / redo log / flush method / IO capacity）、各自如何影響讀寫吞吐、配置 step-by-step、5 production 踩雷（buffer pool warm-up / log file 大小 / 設 sync_binlog=0 換速度 / IO scheduler / undo log 膨脹）、跟 SSD / NVMe / EBS 的 IO 假設
• 2026-05-19 MySQL Binary Log + CDC：Maxwell / Debezium 是 binlog 第二消費者 MySQL CDC 跟 PostgreSQL logical decoding 是不同 abstraction — PG logical decoding 是 *logical event*（INSERT / UPDATE / DELETE）、MySQL CDC 是 *讀 binlog row-level event*。Maxwell / Debezium 是 binlog 第二消費者（跟 replica 共享 binlog stream），並非 PostgreSQL 式 logical replication 系統。本文走 binlog 三種 format（STATEMENT / ROW / MIXED）、ROW format 的 raw event 結構、Maxwell vs Debezium 對比、配置 step-by-step、5 production 踩雷（binlog retention / DDL event / row image / Kafka producer 跟 binlog reader 速度差 / schema change 跟 CDC consumer 同步）
• 2026-05-19 MySQL Vitess Sharding：VTGate / VTTablet / VReplication / VSchema 四件套協作 Vitess 不只是 MySQL sharding proxy、是 4 個 component 協作的完整 sharding 系統 — VTGate（query routing layer）、VTTablet（per-MySQL agent）、VReplication（跨 shard 資料移動）、VSchema（sharding metadata）。本文走 4 件套各自責任、keyspace / shard / tablet 架構、shard key 設計（Vindex）、配置 step-by-step、5 production 踩雷（cross-shard transaction / VStream lag / Vindex 不均勻 / resharding 切流 / VReplication 卡住）、跟自管 sharding 跟 PlanetScale 的對比
• 2026-05-19 PostgreSQL Citus Distributed：用 extension 把 PG 變成 sharded cluster Citus 是 PG extension、把單機 PG 變成 *coordinator + worker* sharded cluster、保留 PG SQL + 加 distributed table + reference table + columnar storage。本文走 Citus 架構（coordinator / worker / distribution column）、3 種 table type（distributed / reference / local）、配置 step-by-step、5 production 踩雷（distribution column 選錯 / cross-shard transaction / reference table 過大 / colocate 不對齊 / worker failover）、跟 MySQL Vitess sharding sibling 對比
• 2026-05-19 MySQL 8.0 Modern SQL：CTE / window function / JSON_TABLE 不是「終於跟上 PG」、是進入 SQL 工程深度的入場券 MySQL 8.0 在 SQL 特性上 *終於補齊* CTE、window function、lateral derived table、JSON_TABLE、hash join 等現代 SQL 特性。本文走 5 個關鍵特性、各自實際 production 場景、跟 PostgreSQL 對應特性的行為差異（特別是 JSON_TABLE vs PG JSONB / jsonb_path_query）、配置 / migration 注意事項、5 production 踩雷（CTE 不 materialize / window function 大量 sort spill / JSON_TABLE 跟 generated column 取捨 / hash join 預設沒開 / recursive CTE 深度上限）
• 2026-05-19 PostgreSQL SQL Features：PG 早就有的、MySQL 8.0 才補的、PG 仍領先的 PG 在 SQL features 上長期領先 MySQL — CTE / window function / lateral / partial index / FTS / JSONB / GIN index / materialized view 在 PG 早 5-15 年。MySQL 8.0（2018）補多數但 *index / storage / extension* 層仍是 PG 結構優勢。本文整理 PG 早期就有的特性、MySQL 8.0 補的差異、PG 仍領先的、跟 MySQL modern-sql-features sibling 反向視角
• 2026-05-19 MySQL Group Replication / InnoDB Cluster：single-primary vs multi-primary mode 對 transaction certification 的影響 MySQL Group Replication 提供 synchronous multi-primary replication、用 Paxos-like Group Communication Engine（GCE）達成 quorum-based commit。但「multi-primary」不是「single-primary 多開幾個 write 入口」、是 *transaction conflict detection + certification* 整個機制不同。本文走 GR 機制（GCE + certification + applier）、single-primary vs multi-primary mode、InnoDB Cluster 跟 MySQL Shell / Router 整合、5 production 踩雷（cert lag / write conflict / large transaction / network partition / member 加入 catch-up）、何時用 GR 何時用傳統 replication
• 2026-05-19 PostgreSQL BDR / Multi-Master：active-active 寫入的 3 種路徑跟 conflict 治理 PG 預設是 single-primary、active-active 多寫入入口需要 *BDR (EDB)* / *pgEdge* / *Bucardo* 等 extension。本文走 3 種 multi-master 方案對比、conflict detection + resolution model、async vs sync 取捨、配置 step-by-step（pgEdge 為主）、5 production 踩雷（last-write-wins data loss / sequence collision / DDL replication / conflict log 治理 / failover 後 timeline 分歧）、跟 MySQL Group Replication sibling 對比
• 2026-05-19 MySQL Query Optimization：從 EXPLAIN 看到實際執行、5 條 query 從 5 秒變 50ms 的 anatomy MySQL query 慢的根因不在「SQL 寫法」、在「optimizer 選錯 plan」。本文從 5 個常見 production case 開場（5 秒 → 50ms / 30 秒 → 200ms / 8 秒 → 30ms 等）、走 EXPLAIN / EXPLAIN ANALYZE / optimizer trace 三層分析工具、index hint vs optimizer hint 取捨、cardinality estimation 失效時的修法、5 production 踩雷（statistics 過時 / forced index 用錯 / hash join 沒觸發 / range scan 退化 ALL / derived table materialization）
• 2026-05-19 PostgreSQL Query Optimization：EXPLAIN ANALYZE / pg_hint_plan / auto_explain 三層工具跟 4 個 case PG query 慢的根因常是 *planner 選錯 plan 或 statistics 過時*。本文從 4 個 production case 開場（seq scan vs index / hash vs nested loop / 多 column 統計缺 / parallel query 沒觸發）、走 EXPLAIN / EXPLAIN ANALYZE / auto_explain 三層工具、pg_hint_plan extension 跟 planner GUC 取捨、5 production 踩雷（ANALYZE 過時 / multi-column statistics / cost-base setting 不對齊硬體 / random_page_cost SSD 沒調 / parallel query 配置）、跟 MySQL query-optimization sibling 對比
• 2026-05-19 MySQL Partitioning：partition lifecycle 五段、跟 Vitess sharding 不同的「同 instance 內水平切割」 MySQL native partitioning 是 *同一個 MySQL instance 內的水平切割*、不是 Vitess sharding（跨 instance）。本文走 partition lifecycle 五段（design → create → query → maintenance → drop）、4 種 partition type（RANGE / LIST / HASH / KEY + COLUMNS / sub-partitioning）的 trade-off、partition pruning 怎麼運作、5 production 踩雷（PK 必須含 partition key / global index 沒原生 / partition exchange 細節 / orphan partition / cross-partition query 慢）、跟 PG declarative-partitioning 對比
• 2026-05-19 MySQL PITR + Backup Strategy：備份不是「拷貝資料」、是 N 點任意 restore 的能力 MySQL backup 不只是 mysqldump、是 *full backup + binlog 連續流* 組合才能達成 PITR（point-in-time recovery）。本文走「PITR 是能力、不是動作」、3 種 backup tool 對比（mysqldump / Percona XtraBackup / MyDumper）、binlog-based recovery 流程、配置 step-by-step、5 production 踩雷（GTID 處理不一致 / binlog gap / backup 沒 verify / RPO 不到 1 分鐘的代價 / encryption key 沒備份）、跟 PG pitr-wal-archiving sibling 對比
• 2026-05-19 MySQL Lock Contention：在 staging 重現的 deadlock、production 跑 6 個月才出現 MySQL InnoDB 的 lock 是 row-level、但 *為什麼某些 row 莫名其妙也被 lock* 是 gap lock / next-key lock 設計造成的隱性行為。本文從一個 production case 開場（staging 重現 deadlock / production 6 個月後突然爆）、走 5 種 InnoDB lock 類型（record / gap / next-key / insert intention / auto-inc）、isolation level 對 lock 行為的決定性影響、deadlock detection / SHOW ENGINE INNODB STATUS 解讀、5 production 踩雷（gap lock 阻塞 INSERT / auto-inc lock contention / FK lock cascading / large transaction lock holding / READ COMMITTED 跟 binlog ROW 互動）
• 2026-05-19 PostgreSQL MVCC + Lock Model：為什麼 PG 比 MySQL 少 deadlock、但 vacuum 是別的代價 PG 用 *MVCC-heavy + 少 explicit lock* 的並行控制、跟 MySQL InnoDB 的 *lock-based*（record / gap / next-key）相反。本文走 MVCC 機制（tuple version + xmin/xmax + visibility）、PG 4 種 lock（row-level / table-level / advisory / predicate）、預測 SERIALIZABLE 行為、5 production 踩雷（idle transaction 卡 vacuum / SELECT FOR UPDATE 跨 transaction / advisory lock 沒釋放 / bloat 不是 vacuum 問題 / predicate lock 在 SSI 下 rollback）、跟 MySQL lock-contention sibling 對比
• 2026-05-19 MySQL 5.7 → 8.0 Major Version Upgrade：character set / authentication / atomic DDL 三條 paradigm 同時換軌 MySQL 5.7 → 8.0 三條 default 同時改：charset utf8 → utf8mb4、auth plugin native_password → caching_sha2_password、DDL non-atomic → atomic。本文走 Type E paradigm shift 結構、6 維 audit、4-phase upgrade、5 production 踩雷、何時不要升級。
• 2026-05-19 PostgreSQL JSONB Deep Dive：Binary Storage + GIN Index 為什麼是結構性優勢 PG JSONB（9.4+）是 *binary 儲存的 JSON*、可直接 GIN index、是 PG 在 JSON workload 的結構性優勢、跟 MongoDB / MySQL 8.0 JSON_TABLE 比仍領先。本文走 JSON vs JSONB 差異、GIN index 機制（jsonb_ops vs jsonb_path_ops）、operator + path query、partial JSONB indexing、5 production 踩雷（大 JSONB 跟 TOAST / nested update / index 選錯 op class / jsonb_path_query 跟 jsonb_path_exists 行為差 / partial index 條件搞錯）、何時用 JSONB vs 拆 column
• 2026-05-19 MySQL → Aurora MySQL：storage layer 轉手到 AWS、replication / HA / backup 全部 outsource 自管 MySQL → Aurora MySQL 是 Type C operational hybrid migration — wire protocol 一致、ops 責任轉到 AWS。本文走 6 維 audit（Operational High）、Aurora storage architecture 衝擊、4-phase migration、5 production 踩雷、何時維持原路線。
• 2026-05-19 PostgreSQL Extension Ecosystem：把 PG 變成 vector DB / time-series / sharded 的 plugin 生態 PG 的 extension 機制不只是 plugin、是 *結構性產品線擴張* — pgvector 讓 PG 變 vector DB、TimescaleDB 變 time-series、Citus 變 sharded、PostGIS 變 GIS。本文走 PG extension lifecycle、6 個 production-critical extension（pg_stat_statements / pg_partman / pg_repack / pgvector / TimescaleDB / PostGIS）、5 production 踩雷（extension version 跟 PG version 對齊 / managed PG 限制 / upgrade order / shared_preload_libraries 衝突 / extension 跟 logical replication 互動）、cloud vendor 對 extension 的限制
• 2026-05-19 MySQL → PlanetScale：managed Vitess + branch-based schema workflow 的 hybrid shift 自管 MySQL → PlanetScale 加上 Vitess sharding 跟 branch-based schema workflow。本文走 6 維 audit（Paradigm + Operational + Schema 多軸）、4-phase migration、5 production 踩雷、何時不要遷。
• 2026-05-19 PostgreSQL Full-Text Search：tsvector / tsquery / GIN index 跟 pg_trgm fuzzy 三層搜尋 PG 內建 full-text search 用 *tsvector / tsquery / GIN index* 三件組、適合中小規模搜尋（< 100M 文件）；pg_trgm 提供 fuzzy match。本文走 FTS 機制（tsvector 是 lexeme + position 的 vector）、3 種 query（match / ranking / weighted）、multi-language support、跟 pg_trgm fuzzy match 互補、5 production 踩雷（dictionary 選錯 / GIN 跟 GiST 取捨 / ranking 評分權重 / multi-language column 處理 / 何時不該用 PG FTS 改 Elasticsearch）
• 2026-05-19 PostgreSQL Replication Slot Management：Physical / Logical / Failover Slot 治理 PG replication slot 是 *primary 端的 standby 進度紀錄*、防 WAL premature deletion。但 orphan slot 會吃 disk、failover 後 logical slot 不會自動跟新 primary、是 PG 操作的 hidden complexity。本文走 physical / logical slot 差異、slot lifecycle、failover slot synchronization（PG 17+ 新特性）、orphan slot 治理、5 production 踩雷（orphan slot disk 爆 / logical slot lag / failover 後 slot 丟 / wal_keep_size 跟 slot 衝突 / connection 同時打 slot 數量限制）
• 2026-05-19 自管 Vitess → PlanetScale：Vitess component ops outsource、加 schema workflow shift 自管 Vitess → PlanetScale 是 Type C operational hybrid — Vitess component（VTGate / VTTablet / VReplication / VSchema）ops outsource + branch workflow。本文走 6 維 audit、4-phase migration、5 production 踩雷、何時不要遷。
• 2026-05-19 TimescaleDB Deep Dive：Hypertable / Continuous Aggregate / Compression 把 PG 變 Time-Series DB TimescaleDB 是 PG extension（不是 fork）、用 *hypertable* 自動 partition by time、加 *continuous aggregate* 做 incremental materialized view、加 *compression* 對舊 chunk 壓 90%+、把 PG 變成 InfluxDB / Prometheus 級 time-series DB。本文走 hypertable 機制、continuous aggregate 跟普通 MV 差異、compression policy、retention policy、5 production 踩雷（chunk size 不對 / CAGG refresh 落後 / compression 後 update 限制 / hypertable 不能加 FK / TimescaleDB 跟 PG 主版本對齊）、跟 PG 原生 partitioning 對比
• 2026-05-27 Aurora Storage Architecture：quorum-based 分散式 log 與韌性即性能設計 Aurora storage / compute 分離、6-way 跨 AZ replication、4-of-6 write / 3-of-6 read quorum、韌性投資自動 amortize 成 read 性能、DraftKings 6ms 寫 / <1ms 讀 production reference
• 2026-05-27 CockroachDB HLC + Raft Consensus：軟體時鐘 + per-range 共識的 latency 與容量結構 CockroachDB 用 Hybrid Logical Clock + per-range Raft 做跨節點線性化、不靠 TrueTime 原子鐘。本文走 HLC / Raft / range / leaseholder 四層機制、寫入 latency 構造、failure mode（clock skew panic / Raft majority lost / hot range）、引用 DoorDash Aurora 撞牆訊號（1.636 M QPS 屬 Aurora 痛點而非 CockroachDB 容量證明）+ Netflix 380+ artery of small DBs 容量規劃顆粒
• 2026-05-27 Cosmos DB MongoDB API vs SQL API：遷移路徑、dogfood signal、multi-model、跨雲 hedging 從『MongoDB API 跟 SQL API 哪個快』推進到 vendor selection 的四層問題：三型遷移路徑、dogfood signal 怎麼讀、multi-model 差異化、跨雲 hedging — 從 Microsoft 365 dogfood 案例切入
• 2026-05-27 DynamoDB Single-Table Design：從適用度前置判讀到 access pattern 反推 PK/SK DynamoDB single-table 設計不是「資料表越少越好」，而是 access pattern 反推 PK/SK 跟 GSI；本文先做 DynamoDB 適用度 4 軸前置判讀（PK 天然均勻 / control plane vs data plane / consistency / access pattern 穩定），再展開設計流程、failure modes 與 durable queue 正向用例
• 2026-05-27 MongoDB Schema Design Pattern：contract layer 在哪 vs embedded / reference MongoDB document schema 真正的 production 議題不是 embedded vs reference 二選一、是 schema contract 該放 DB 層 validator 還是 app 層 abstraction；含 Toyota polymorphic governance、Forbes abstraction layer、time-series collection 邊界
• 2026-05-27 Spanner TrueTime API 深度：GPS + 原子鐘、commit wait、為什麼 line-rate scaling 才是設計目的 TrueTime 是手段、line-rate scaling 才是 Spanner 的設計目的。本文先扣商業邏輯：傳統 OLTP coordinator 為什麼是 bottleneck、Spanner 怎麼用 TrueTime + Paxos 換成拓樸感知多 leader；再展開 TrueTime ε / commit wait 數學、ε 暴衝失敗模式、cross-region voting 對 latency 的影響、跟 9.C10 Google internal dogfood 揭露的線性擴展模式對照
• 2026-05-19 pgvector Deep Dive：HNSW / IVFFlat 取捨跟跟專業 Vector DB 對比 pgvector 是 PG extension、加 *vector* type 跟兩種 ANN index（IVFFlat / HNSW）、把 PG 變成可用 vector DB。本文走 vector type + distance operator、IVFFlat vs HNSW 取捨（build time / recall / memory）、quantization 跟 dimension reduction、5 production 踩雷（dimension 超 2000 限制 / HNSW build 太慢 / IVFFlat 不重建 recall 漂移 / hybrid search 設計 / memory budget）、跟 Pinecone / Weaviate / Milvus 對比的決策框架
• 2026-06-02 Aurora Serverless v2 適用判斷：ACU 自動擴縮、混合 cluster 與何時不該用 Aurora Serverless v2 不是「比較便宜的 Aurora」；本文展開 ACU 計費粒度、秒級自動擴縮機制、min/max ACU 設定、serverless 與 provisioned 同 cluster 混用，以及穩定高負載下 serverless 反而更貴的成本 crossover 邊界
• 2026-05-27 DynamoDB Partition Key 反模式與 Write Sharding：composite key 修復跟 mode × partition 交叉判讀 DynamoDB partition 上限 1000 WCU 是 hot partition 的根因；composite key（event_id + shard suffix）跟 calculated shard（hash % N）兩種修法、mode × partition 在 provisioned / on-demand 不同表現，以及 9.C15 Tixcraft 6750x 擴展的工程細節
• 2026-05-27 MongoDB Shard Key Selection：hashed vs ranged、單 cluster 切 shard vs 多 cluster 切 blast radius MongoDB sharded cluster shard key 選型（hashed / ranged / compound）、單 cluster 分 shard vs 多 cluster 分 blast radius 對照、跟 DynamoDB / Cosmos DB partition key 可逆性的跨 vendor 紀律
• 2026-05-27 Spanner Consistency Models 對照：external consistency vs serializability vs linearizability external consistency、serializability、linearizability 是三個常被混用的概念。本文先精確定義三者差異、再用 line-rate scaling 對照表（PG SSI / CockroachDB / Spanner / Aurora DSQL）回答為什麼 Spanner 不只是『更強的 serializable』、最後用 9.C10 揭露的 cross-region quorum 100-200ms 物理硬限解釋『強一致 + 全球部署』的真實 cost
• 2026-05-19 PostGIS Deep Dive：Geometry / Geography 型別、GiST 空間索引跟 ST_* 函式生態 PostGIS 是 PG extension、加 *geometry* / *geography* 型別、GiST 空間索引跟 1000+ ST_* 函式、把 PG 變成功能完整 GIS DB（跟 Oracle Spatial / SQL Server geography 並列）。本文走 geometry vs geography 取捨、SRID 跟投影系統、GiST 空間索引機制、5 production 踩雷（geometry 用錯 SRID / geography 不能用所有 ST_ 函式 / GiST index 不對 ST_DWithin 生效 / cluster on geom 後 BRIN 失效 / EWKB vs WKB 跨工具相容）、GIS workload 的 PG vs 專業 GIS DB 對比
• 2026-06-02 Aurora 多 cluster 按業務切分：微服務私有 store、blast radius 隔離與 fleet 治理 把所有服務塞進一個大 Aurora cluster 會讓單一服務的查詢拖垮全部；本文展開按業務 / 微服務切 cluster 的判斷維度、blast radius 隔離、共用 vs 分離的成本與運維 surface 權衡，以及多 cluster fleet 的治理一致性，含 Netflix Aurora consolidation 對照
• 2026-05-27 DynamoDB GSI 與 LSI 設計：access pattern 補位、projection、consistency 跟 DAX 補位 GSI / LSI 是 single-table 沒覆蓋的 access pattern 補位、不是萬靈丹；本文涵蓋 projection 三型選擇、sparse index、GSI 自己會 hot partition、DAX 讀峰值補位的觸發條件（含 Capcom 是 derive vs Lemino 是 case fact 的分層）
• 2026-05-27 MongoDB Replica Set Read Preference：DB 層 causal session vs cache 層 freshness token MongoDB read preference 五擇一 + read concern + causal consistency session 機制；DB 層機制解 cluster 內 read-your-own-write、cache 層 freshness token 解跨層 read-after-write、大規模 OLTP 必須兩層合用
• 2026-05-27 Spanner Schema Migration Without Downtime + Interleaved Tables Spanner DDL 是 long-running operation、用 TrueTime 給每次 schema change 分配 version timestamp、所有 read / write 對應自己 transaction timestamp 看到對應 schema。Interleaved table 是 storage-level parent-child 物理交錯、不是 logical FK。本文走 schema change lifecycle、interleaved layout 機制、backfill capacity 影響、5 production 踩雷、跟 PostgreSQL online schema change 對照
• 2026-05-18 PostgreSQL autovacuum tuning：為什麼你的 autovacuum 永遠追不上 bloat MVCC 怎麼產生 dead tuple、autovacuum cost-based throttle 為什麼預設保守、per-table tuning 怎麼設、5 個 production 踩雷（cost_limit 太低 / 長 transaction blocks vacuum / anti-wraparound 在 peak / partition vacuum 滿 worker / index bloat 沒處理）、跟 partitioning + monitoring 整合
• 2026-06-02 Aurora RDS Proxy 與連線管理：connection multiplexing、pinning 陷阱與 failover 加速 RDS Proxy 不是「連上去就自動省連線」；本文展開 connection multiplexing 機制、哪些 session 操作會觸發 pinning 讓 multiplexing 失效、failover 期間 proxy 如何保持 client 連線縮短中斷，以及 RDS Proxy 與自管 pgbouncer 的責任切分
• 2026-05-27 DynamoDB On-Demand vs Provisioned：6 軸決策、auto-scaling 邊界與 cost crossover capacity mode 選擇不是單軸 peak/avg ratio；本文展開 6 軸決策（peak/avg / 讀寫比 trend / surge 暫時 vs 永久 baseline / predictable-peak vs flash-sale / DBA 工時釋放 / vendor vs 自管 cost crossover），含 Zomato 50% 成本下降、Zoom 30x permanent surge、Amazon Ads sustained workload 等 case 分軸 anchor
• 2026-05-27 Migration Playbook：Cloud SQL for PostgreSQL → Cloud Spanner Cloud SQL → Spanner 是 paradigm shift 級遷移、不是 drop-in。本 playbook 走 6 規格面 Driver / Diff / Phase / Evidence / Cutover / Cleanup：Driver 段明示 sizing barrier（100 pu 起跳）跟 < 50ms write latency 兩條 no-go；Diff 段加 sizing / cost 第 7 規格面；Phase 0 含 sizing audit；Evidence 段補 cost crossover 報告；對照 9.C10 Google internal dogfood 邊界跟 Standard Chartered 受監管 banking case
• 2026-05-27 MongoDB Connection Management and Cache Layer：driver × 部署模型 × cache × predictive scaling MongoDB 大規模 OLTP 撞牆不是單一 driver 議題、是 driver × 部署模型 × cache × scaling trigger 三層協作；含 Coinbase mongobetween / freshness token / ML 預測擴容三件套 + 適用範圍紀律
• 2026-05-18 PostgreSQL declarative partitioning：partition 不是切表、是讓 planner pruning Declarative partitioning 的真實價值是 query planner pruning + maintenance scope 縮小、不是「把大表切小」；RANGE / LIST / HASH 取捨、partition key 選法、5 個 production 踩雷（key 選錯不 prune / unique 不 enforce 跨 partition / ATTACH 鎖太久 / partition 數爆 / DETACH 不 reclaim 空間）、跟 autovacuum + index 設計整合
• 2026-06-02 Aurora PG/MySQL vs Aurora DSQL 取捨：何時 single-region managed 夠用、何時跨到 distributed Aurora DSQL 不是 Aurora 的升級版而是不同 paradigm；本文聚焦『standard Aurora（single-region managed SQL）什麼時候夠用、什麼時候需要跨到 active-active distributed』的升級門檻決策，切分『怎麼遷』（migrate-to-aurora-dsql）與『DSQL vs Spanner vs CockroachDB 三方選型』（decision-tree）兩個既有 SSoT
• 2026-06-02 Spanner Change Streams (CDC)：捕捉資料變更、watch partition、下游整合與 DynamoDB Streams 對照 Change Streams 是 Spanner 把 commit 後的 row mutation 變成可消費事件流的 CDC 機制、用 data change record 攜帶 commit timestamp 把外部一致性延伸到下游。本文走 change stream 物件模型、watch partition 的 child partition 切分、Dataflow / Pub/Sub 下游整合、retention 與 staleness 失敗模式、跟 DynamoDB Streams 的 partition / ordering / retention 對照
• 2026-05-27 DynamoDB Global Tables：multi-region active-active、LWW conflict 與 cross-device sync 正向用例 Global Tables 不只是 conflict 痛點、也是 cross-device sync / global read / DR failover 的正向工程方案；本文展開 B2B SaaS vs B2C 業務 driver、LWW conflict resolution、reconciliation pipeline，含 Genesys 99.999% 跨 15 region 跟 Disney+ 跨裝置同步的對照
• 2026-05-27 MongoDB Aggregation Pipeline Optimization：stage 順序、index 配合與 memory 邊界 MongoDB aggregation pipeline stage 順序、index 配合、100MB memory 邊界、cross-shard `$lookup` 限制；report dashboard 跑爆 primary 的 anti-pattern 治理路徑
• 2026-05-18 PostgreSQL Logical Replication + Debezium CDC：replication slot × failure × recovery 對照 PostgreSQL logical replication slot 跟 Debezium CDC 的失效模式對照表：slot lag 撐爆 primary disk / schema change 斷流 / 初始 COPY 鎖表 / zombie slot 不釋放 / replay storm 後 offset reset；publication / subscription / pgoutput 配置、跟 Kafka outbox pattern 整合
• 2026-06-02 DynamoDB Transaction 與 Conditional Write：跨 item 原子性、optimistic locking 與 idempotency DynamoDB 的寫原子性不是免費 ACID；本文展開 TransactWriteItems 跨 item 原子性、ConditionExpression 條件寫、version-based optimistic locking、ClientRequestToken idempotency，以及 transaction 2x 成本邊界與何時用單 item conditional write 取代 transaction
• 2026-06-02 Spanner PostgreSQL dialect：PG-compatible interface vs GoogleSQL、相容子集邊界、何時選 PG dialect Spanner PostgreSQL dialect 是建在 Spanner 分散式引擎之上的 PG-compatible 介面、提供 PostgreSQL 語法、型別與 wire protocol、但不是完整 PostgreSQL。本文先定義 PG dialect 跟 GoogleSQL dialect 的責任差異、再劃相容子集邊界（哪些 PG 功能不在、哪些 Spanner-only 概念仍要懂）、最後給選 dialect 的決策判準與 dialect 不可變更的失敗代價
• 2026-05-27 MongoDB Change Streams + Kafka 整合：resume token、scope 選擇與 connector 治理 MongoDB change streams 機制（resume token、oplog 容量、cluster-wide vs collection-level scope）跟 Kafka Connector 整合；at-least-once 語義 + idempotency 治理 + resume token 過期防護
• 2026-05-18 PostgreSQL PITR + WAL archiving：從 base backup 到 point-in-time recovery 的完整鏈 Base backup + WAL archive 構成 PITR 的雙軌資料、archive_command + restore_command 配置、用 pgBackRest / WAL-G 替代手寫腳本、5 個 production 踩雷（archive 靜默失敗 / archive lag / 錯誤 target time / base backup 過期未清 / timeline 分歧 recovery 模糊）、跟 Patroni + monitoring 整合
• 2026-06-02 DynamoDB DAX 快取策略：cluster 架構、item/query cache、write-through 與 invalidation 邊界 DAX 不是「加上去就變快」的開關；本文展開 DAX cluster 架構、item cache vs query cache 兩種快取、write-through 一致性語意、query cache 只靠 TTL 失效的陷阱，以及 strongly consistent read 繞過 cache 的邊界，含 Lemino 讀峰值補位 case fact 與 gsi-lsi-design 的 SSoT 切分
• 2026-06-02 Spanner Graph (2024)：property graph 能力、跟 relational 表共存、適用場景與邊界 Spanner Graph 是建在 Spanner relational 引擎上的 property graph 能力、用 GQL 查詢 node 與 edge、底層仍是 relational table、graph 跟 SQL 共用同一份資料與 transaction。本文走 graph 物件模型（node / edge table 映射）、跟 relational 共存的設計、GQL 查詢、graph schema 不可逆設計的失敗代價、何時用 graph、何時用純 relational 或專用 graph DB
• 2026-06-02 DynamoDB Streams 與 Lambda 事件驅動：CDC、shard 順序保證、消費模式與失敗處理 DynamoDB Streams 不是免費的可靠事件流；本文展開 stream record 的四種 view type、shard 對應 partition 的順序保證邊界、Lambda event source mapping vs Kinesis 消費模式、at-least-once 下游冪等需求，以及 batch 失敗時的 bisect / DLQ 處理
• 2026-06-02 Spanner ↔ BigQuery federation：OLTP/OLAP 分工、federated query、Data Boost、何時把分析 workload 分出去 Spanner 是 OLTP、BigQuery 是 OLAP、federation 讓 BigQuery 直接查 Spanner 的活資料、Data Boost 讓分析查詢用獨立運算資源不搶 OLTP CPU。本文先定義 OLTP/OLAP 的責任分工、再走 external dataset federated query、Data Boost 的 workload 隔離機制、federation vs change-stream-to-BigQuery 兩條整合路線的取捨、以及何時該把分析 workload 完全分出去
• 2026-06-02 DynamoDB TTL 資料生命週期：自動過期、48 小時刪除延遲、過期仍可讀與 storage 成本 DynamoDB TTL 不是即時刪除也不是查詢過濾器；本文展開 TTL attribute 的 epoch 語意、AWS 背景刪除的延遲特性、過期但未刪 item 仍會被讀到且仍計費的陷阱、TTL 刪除免 WCU 與觸發 stream 的整合，含 PayPay 訊息過期清理 case anchor
• 2026-06-02 從 RDS / MongoDB 遷移到 DynamoDB：access-pattern-first 重建模、混合架構與 cost crossover RDS / MongoDB → DynamoDB 不是搬 schema 而是換 paradigm；本文走 Type E paradigm shift 結構，展開為何字面遷移不成立、access pattern 重建模、哪些 workload 該遷哪些該留的混合架構、dual-write + shadow read 階段化，以及 Zomato cost crossover 的長期成本判讀
• 2026-05-27 Aurora Cross-AZ Failover：RTO 量測、endpoint routing 與 application reconnect 契約 Aurora cross-AZ failover lifecycle（detection / promotion / DNS update）、< 30 秒 RTO、application DNS cache 跟 connection pool 對齊、Standard Chartered 受監管場景為什麼用獨立 cluster 而非 Global Database failover
• 2026-05-27 CockroachDB Survival Goals：zone 級 vs region 級配置與業務 SLO 倒推流程 CockroachDB 用 SURVIVE ZONE FAILURE / SURVIVE REGION FAILURE 兩種 survival goal 宣告式控制 Raft replica 分佈、決定 RTO / RPO。本文走 Hard Rock Digital bet placement RPO=0 倒推流程、Netflix Gaming 48-node 跨 4 region 「為求 survival 而非 latency」的反直覺判讀、配置語法、寫入 latency 暴漲跟 cost 暴漲兩條失敗模式、合規邊界對比
• 2026-05-27 Cosmos DB RU/s 成本模型 + 容量規劃：RU 思維、payload、index、provisioned vs autoscale vs serverless 從 CPU+IOPS 思維轉到 RU 思維的學習曲線、依負載形狀選容量模式、payload + index policy 對 RU 的影響、autoscale reactive 限制 — 從 ASOS Black Friday + Minecraft Earth 1M RU/s 壓測切入
• 2026-05-19 PostgreSQL major version upgrade (14 → 17)：為什麼這篇不套 5 type migration PostgreSQL major version upgrade 是 *5 type 漏類* 的實證 — source/target 同 vendor、5 維度都 Low 但 *upgrade-specific audit* 是核心；本文結構接近 deep article methodology 的 6-section + 額外 upgrade audit 段；涵蓋 pg_upgrade / logical replication / blue-green 三方法、extension 相容性、5 production 踩雷
• 2026-05-19 PostgreSQL → Aurora Migration：protocol 相容、operational 重設計 Aurora 號稱 PostgreSQL-compatible 但 operational model 不同（storage decouple / cluster endpoint / instance class / 自家備份）；遷移流程是混合（protocol drop-in + operational phased）、5 個 production 踩雷（extension 不支援 / replication slot 不直通 / autovacuum 行為差 / IAM 認證強制 / cost model 換算）、跟 Patroni / read replica / DR 對位
• 2026-05-19 PostgreSQL → Aurora DSQL Migration：PG wire-compatible Distributed SQL 的 Paradigm Shift Aurora DSQL（2024-12 re:Invent preview / 2025-05 GA）是 AWS 推的 PG wire-compatible *active-active distributed SQL*、跟 self-managed PG / Aurora PG 不同 paradigm（OCC + snapshot isolation + multi-region strong consistency）。Migration 結構是 *protocol drop-in + paradigm shift*：app SQL 不太改、但 transaction retry / extension 缺位 / 多 region 一致性需重設計。本文走 DSQL vs Aurora PG vs self-managed PG 三軸對比、為什麼遷的三條 driver（global write / operational zero-touch / region resiliency）、Type E phased plan、5 production 踩雷（transaction retry 沒處理 / extension 缺位 / sequence throughput 限制 / Aurora PG 直升 DSQL 不可行 / region failover semantic）、跟 PG → Aurora 跟 PG → CockroachDB 對比
• 2026-06-26 mysqldump MySQL / MariaDB 的 CLI 備份工具，把資料庫匯出成 SQL 語句的純文字檔
• 2026-05-19 PostgreSQL → CockroachDB：三維皆 High 的多重歸類 migration PostgreSQL → CockroachDB 是 Schema / Operational / Paradigm 三維皆 High 的 multi-axis migration、實證 [#127](/report/content-structure-by-max-diff-dimension/) 的「多重歸類跟 tie-breaking」規則；主結構走 Type E paradigm shift、Schema 差 + Operational redesign 抽出獨立段；涵蓋 transaction model 重設計、SQL dialect gap、5 個 production 踩雷
• 2026-05-19 PostgreSQL Partition Redesign：當 monthly partition 越跑越慢 PostgreSQL partition redesign 是 Type F「topology re-layout」第 2 個 dogfood — 從 monthly partition 改 daily / 從 range 改 list / 從單軸改 sub-partition；6 維 audit 皆 Low + topology 軸 High；涵蓋 partition 不平衡偵測、ATTACH/DETACH 線上重劃、5 個 production 踩雷、跟 partition_pruning + autovacuum 整合
• 2026-06-26 Database Migration 用版本化的 SQL 腳本管理資料庫 schema 的變更歷程，讓 schema 變更可追蹤、可重現、可回退
• 2026-05-19 PostgreSQL Multi-Region GDPR Rollout：政策驅動的 migration 屬本 methodology 嗎 PostgreSQL 單 region → multi-region 同時滿足 GDPR EU residency 是 *政策驅動* 兼 *topology 變動* 兼 *operational redesign* 的多軸 migration；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 提出的 residency axis 候選 — residency 是 driver 還是獨立 audit 軸；涵蓋 logical replication 配 GDPR / 5 個 production 踩雷 / cross-region cost
• 2026-05-27 Aurora Read Replica Scaling：15 replica 上限、lag profile、headroom 預留與 fleet 治理 Aurora 15 replica 上限、共享 storage 為什麼能養大量 replica、事件型容量分級表、DraftKings headroom 預留判讀、FanDuel 雙 SLO 並行、fleet 治理 3 條 driver（business sharding / microservice / 合規）
• 2026-05-27 CockroachDB Transaction Retry Pattern：serializable default 與 application contract 重塑 CockroachDB default SERIALIZABLE、application 必須包 retry loop 處理 40001 serialization_failure。本文走 PG → CockroachDB application contract 重塑視角、SAVEPOINT cockroach_restart 語法、5 種失敗模式（retry storm / 非冪等 / cross-statement state / hot row / long-running transaction）。**整篇是跨 case 合成 frame**：DoorDash case 沒揭露 retry pattern、只揭露 PG wire protocol 相容 + SQL 行為仍要 audit、本章 retry contract 重塑屬通用工程議題從 Cockroach Labs 官方 docs 合成
• 2026-05-27 Cosmos DB Multi-Region Write：active-active、LWW、custom merge、Strong + multi-region 互斥的 AP 取捨 Multi-region active-active write 的 conflict resolution（LWW / custom merge / conflict feed）、Strong 跟 multi-region write 為什麼互斥、廣告 SLA vs 實測可用性鏈路拆解 — 從 Minecraft Earth + Toyota Connected 切入
• 2026-05-27 Aurora Global Database：跨 region async replication、< 1 秒 lag 與合規 anti-recommendation Aurora Global Database 跨 region storage-level async replication、< 1 秒 typical lag、planned vs unplanned failover RTO 數量級對比、Standard Chartered 合規禁止跨境複製為什麼讓 Global Database 變反指標
• 2026-05-27 CockroachDB Locality-Aware Schema：跨州合規 + 邏輯一個 cluster 的 region placement 策略 Hard Rock Digital 跨 8 州 sportsbook、用 AWS Outposts + region placement 把運算釘在州內、邏輯上仍是一個 CockroachDB cluster。本文走 REGIONAL BY ROW / REGIONAL BY TABLE / GLOBAL 三種 locality、Hard Rock 拓樸創新對比 Standard Chartered Aurora 7 cluster fleet、AWS Outposts 是合規工具不是 latency 工具的反直覺判讀
• 2026-05-27 Cosmos DB Partition Key Design：synthetic / composite / hierarchical + 不可逆性硬約束 Cosmos DB logical partition 10000 RU/s 上限、partition key 不可改、三種設計模式（synthetic / composite / hierarchical）、跟 DynamoDB / MongoDB 可逆性對比、latency budget 拆解 — 從 Minecraft Earth + ASOS 切入
• 2026-06-02 CockroachDB Multi-region Table 配置：三種 table locality 的選擇與 latency / 一致性取捨 CockroachDB 把 multi-region table 抽象成 REGIONAL BY TABLE / REGIONAL BY ROW / GLOBAL 三種 locality、每種對 read / write latency 跟一致性付不同成本。本文走三種 locality 的判讀軸、survival goal 怎麼跟 locality 一起決定副本拓樸（機制本身 cross-link survival-goals）、配置與驗證流程、選錯要重配的高代價回退、容量觀測訊號
• 2026-05-27 Cosmos DB 5 Consistency Levels：Session 預設、Bounded staleness、Strong 邊界跟跨 collection 分流策略 Cosmos DB 5 個 consistency level 的工程選擇邏輯、Session 為何是 production 預設、per-request override 跟跨 collection 分流的進階策略、Strong + multi-region 互斥的 cross-link — 從 Minecraft Earth + ASOS 切入
• 2026-05-27 從自管 PostgreSQL / MySQL 遷到 Aurora：operational redesign migration playbook PostgreSQL / MySQL → Aurora 的 Type C operational redesign hybrid playbook、6 規格面（Driver / Diff audit / Phase plan / Evidence / Cutover / Cleanup）、Standard Chartered 合規 lead time 模型、Netflix 非 all-purpose store 邊界
• 2026-06-02 Cosmos DB Change Feed (CDC)：persistent change log、Azure Functions trigger、latest-version vs all-versions-and-deletes 與跟 DynamoDB Streams 對照 Cosmos DB Change Feed 的工程展開：partition-scoped 持久變更 log、change feed processor 的 lease / continuation token、latest-version 與 all-versions-and-deletes 兩種模式的取捨、Azure Functions trigger 整合、跟 DynamoDB Streams 的語義差 — 從 ASOS catalog 寫入投影切入
• 2026-06-02 Cosmos DB Stored Procedure / Trigger（JavaScript）：partition-scoped 交易、server-side 邏輯邊界、何時用何時讓 application 層處理 Cosmos DB 用 JavaScript 寫的 stored procedure、pre/post trigger 與 UDF 的工程展開：single-partition transaction 語義、bounded execution 與 continuation 模式、何時值得用 server-side 邏輯、為何多數邏輯應留在 application 層 — 跟 Change Feed 的非同步路徑對照
• 2026-06-02 從 MongoDB / Cassandra 遷入 Cosmos DB：protocol-compat API drop-in vs native API paradigm shift、相容性邊界與 dual-write cutover MongoDB / Cassandra 遷入 Azure Cosmos DB 的 migration playbook：用 Cosmos 的 MongoDB API / Cassandra API 做 wire-protocol drop-in（Type B）vs 換 native SQL API 的 paradigm shift（Type E）兩條路徑的取捨、6 維 diff audit、相容性邊界、dual-write 與 cutover — 從 Microsoft 365 / Forbes 遷移對照切入
• 2026-06-02 Cosmos DB for PostgreSQL：基於 Citus 的分散式 PostgreSQL、跟核心 Cosmos DB 是不同產品、何時選它而非核心 Cosmos 或一般 PG Cosmos DB for PostgreSQL（2022、Citus-based distributed PG）的定位釐清：它是分散式 PostgreSQL、不是 NoSQL Cosmos DB；distribution column / coordinator-worker 架構、何時選它而非核心 Cosmos DB、何時夠用一般 Azure Database for PostgreSQL — 命名混淆的選型陷阱
• 2026-06-02 Cosmos DB ↔ Azure Synapse Link：analytical store、HTAP federation、何時把分析 workload 從 OLTP 分出去 Cosmos DB Azure Synapse Link 的工程展開：column-oriented analytical store 自動同步、HTAP federation 讓分析 query 不打 OLTP transactional store、no-ETL 對 RU 的隔離、何時把分析 workload 從 Cosmos OLTP 分出去 vs 何時 federate 到專用 OLAP — 從 Microsoft 365 analytics 切入
• 2026-06-02 CockroachDB Cloud Serverless 適用判斷：按用量 vs dedicated 的取捨與 RU 計費結構 CockroachDB Cloud 的 serverless（按用量 RU 計費、自動 scale-to-zero）跟 dedicated（固定 cluster、自管容量）解不同的容量壓力。本文走 serverless 的 RU 計費結構與冷啟動 / scale 行為、何時 serverless 何時 dedicated 的判讀軸、用量暴衝的成本失控回退、跟 self-managed（Netflix Platform Team / Hard Rock 賽季擴縮）的責任對照
• 2026-05-27 CockroachDB vs Aurora DSQL vs Spanner：撞牆訊號分型 + 七問題決策樹 Distributed SQL 三選一決策樹。先用撞牆訊號分型識別 driver path（DoorDash 單主寫入撞牆 / Netflix Cassandra 缺口 / Hard Rock 合規驅動）、再走七問題（跨雲 / 雲商生態 / 風險預算 / PG 相容 / 管理負擔 / team size / vendor sizing barrier）。PostgreSQL 相容性 audit checklist 4 項、Spanner 100 pu sizing barrier、Hard Rock 「省 10-20 工程師」機會成本警示、Netflix Database Platform Team 規模
• 2026-05-18 PostgreSQL pgBouncer 配置 + 連線池治理 pgBouncer transaction pooling 配置、跟 application connection pool 的分層、production 故障演練（pool exhaustion / stale connection / DNS failover）跟容量規劃
• 2026-05-11 Validation Query 說明遷移、回填與修復期間如何用查詢證明資料語意是否一致
• 2026-05-11 Read Compatibility 說明資料或服務演進期間讀取路徑如何同時支援新舊語意
• 2026-05-11 Fallback Read 說明讀取路徑切換失敗時如何暫時回到舊資料語意或舊讀取來源
• 2026-06-22 Event Log 說明事件歷史如何保存、重播與支援跨服務資料重建
• 2026-05-11 Mapping Table 說明遷移或轉換期間如何把舊語意明確對應到新語意
• 2026-06-22 Search Index 說明搜尋索引如何承擔全文檢索、排序與查詢體驗
• 2026-06-22 Read Model 說明為查詢場景建立的讀取模型，與正式狀態的責任分離
• 2026-06-22 Projection 說明從事件流或資料變更推算出查詢用讀取視圖的轉換機制
• 2026-06-22 Materialized View 說明預先計算並儲存查詢結果以加速讀取的資料結構
• 2026-06-22 Event Sourcing 說明用 append-only 事件流取代 mutable state 作為正式紀錄的設計模式、需求判準與代價
• 2026-06-16 Firestore Distributed Counter Lab 在 emulator 上實作 distributed counter：建立 N 個 shard、隨機分片寫入、觀察 shard 分佈是否均勻、讀取彙總驗證總和正確，並說明 contention 本身是 emulator 不模擬的 production 特性
• 2026-06-16 Firestore Local Emulator Quickstart 用 Firebase CLI 啟動 Firestore emulator、寫 firestore.rules、用 admin SDK seed 資料、跑 query baseline 與 cleanup，建立後續 Security Rules 與 distributed counter lab 共用的本地環境
• 2026-06-16 Firestore Security Rules Test Lab 用 @firebase/rules-unit-testing 在 emulator 上把 Security Rules 寫成自動化測試：放行 / 越權拒絕 / 未登入拒絕 / 欄位竄改拒絕四類斷言、firebase emulators:exec 在 CI 跑、把規則測試接進 release gate
• 2026-06-15 終端機 SQL 客戶端：harlequin、lazysql 與 pgcli/litecli 的選型 在純文字終端機連資料庫、跑查詢、看結果的客戶端：全螢幕 TUI（harlequin IDE 風、lazysql 瀏覽器風）與增強型 REPL（pgcli/litecli）兩種範式，以及遠端連線的 SSL driver gotcha。
• 2026-05-22 Aurora PostgreSQL I/O-Optimized Cost Aurora PostgreSQL Standard 與 I/O-Optimized 的成本模型、I/O 壓力、workload 判斷、遷移與回退條件
• 2026-05-22 Managed PostgreSQL Comparison RDS PostgreSQL、Aurora PostgreSQL、Cloud SQL、Azure Database for PostgreSQL、Neon、Supabase、Crunchy Bridge 的責任邊界比較
• 2026-05-22 MySQL Audit Log + SIEM MySQL audit log、general log、slow log、privilege event、SIEM pipeline、retention 與 alert route
• 2026-05-22 MySQL Backup Restore Drill MySQL logical dump、physical backup frame、binlog position、restore validation 與 RPO / RTO evidence
• 2026-05-22 MySQL Cross-buffer Memory Contention MySQL InnoDB buffer pool、sort / join buffer、tmp table、thread memory、OS page cache 與 memory pressure 判讀
• 2026-05-22 MySQL Document Store / X Protocol MySQL Document Store、X Protocol、JSON collection、SQL interoperability、MongoDB-like API 與使用邊界
• 2026-05-22 MySQL Encryption / TLS / Key Management MySQL at-rest encryption、TLS、keyring、certificate rotation、backup encryption 與 credential governance
• 2026-05-22 MySQL HeatWave OLAP Add-on MySQL HeatWave、OLTP + OLAP hybrid、query offload、cost model、data freshness 與 warehouse 邊界
• 2026-05-22 MySQL Local Lab Quickstart MySQL local lab 的 Docker Compose、schema seed、sample workload、basic metric 與 teardown
• 2026-05-22 MySQL Metadata Lock Deep Dive MySQL metadata lock、DDL blocking、long transaction、online schema change、MDL observability 與 incident runbook
• 2026-05-22 MySQL Multi-source Replication MySQL multi-source replication、channel、consolidation、conflict boundary、lag monitoring 與 migration route
• 2026-05-22 MySQL Online Schema Change Lab MySQL ALTER TABLE、metadata lock、gh-ost / pt-osc frame、cutover evidence 與 rollback note
• 2026-05-22 MySQL ProxySQL Routing Lab MySQL ProxySQL hostgroup、read/write split、query rule、backend health 與 routing evidence
• 2026-05-22 MySQL Replication Failover Lab MySQL source / replica、replication lag、promotion、client route、Orchestrator frame 與 validation evidence
• 2026-05-22 MySQL Vitess Sandbox Route Vitess sandbox、keyspace、shard、VSchema、query routing、resharding preview 與 MySQL migration evidence
• 2026-05-22 PostgreSQL Connection Pool Lab PostgreSQL application pool、PgBouncer、backend connection、pool exhaustion 與 failover reconnect 的操作說明
• 2026-05-22 PostgreSQL Connection Pooler Comparison PostgreSQL PgBouncer、Odyssey、RDS Proxy、application pool 與 transaction pooling 的選型比較
• 2026-05-22 PostgreSQL Cross-region DR PostgreSQL 跨區災難復原、physical replica、logical replication、backup restore、RPO / RTO 與 failover runbook
• 2026-05-22 PostgreSQL Developer / DBA Responsibility Split PostgreSQL application developer、DBA、platform team 在 schema、query、migration、backup、incident 與 capacity 的責任分工
• 2026-05-22 PostgreSQL HA Failover Drill PostgreSQL Patroni 或 managed failover 的 promotion、client reconnect、pooler behavior 與 incident timeline
• 2026-05-22 PostgreSQL Local Lab Quickstart PostgreSQL local lab 的 Docker Compose、schema seed、sample workload、basic metric 與 teardown
• 2026-05-22 PostgreSQL Logical Decoding Plugins PostgreSQL logical decoding output plugin、pgoutput、wal2json、test_decoding、CDC connector 與 plugin 選型
• 2026-05-22 PostgreSQL pg_partman Advanced PostgreSQL pg_partman 自動分區、premake、retention、maintenance job、partition migration 與 runbook
• 2026-05-22 PostgreSQL PITR Restore Drill PostgreSQL base backup、WAL archive、target time restore、validation query 與 RPO / RTO evidence 的操作說明
• 2026-05-22 PostgreSQL Schema Migration Evidence Lab PostgreSQL expand / contract migration、validation query、rollback condition 與 release gate evidence 的操作說明
• 2026-05-22 PostgreSQL Security / RLS / Audit Logging PostgreSQL role、grant、Row Level Security、pgAudit、log policy、PII access evidence 與合規路由
• 2026-05-22 PostgreSQL to YugabyteDB / TiDB Migration PostgreSQL 轉向 YugabyteDB、TiDB 類 distributed SQL 的 compatibility audit、data topology、transaction、cutover 與 rollback
• 2026-05-22 Specialized PostgreSQL Variants pgvectorscale、Citus、TimescaleDB、PostGIS、AlloyDB、Cosmos DB for PostgreSQL、serverless PG 等 PostgreSQL 變體的選型邊界
• 2026-05-21 PostgreSQL to SQLite Simplification PostgreSQL 降低操作成本轉向 SQLite 的適用條件、資料責任縮小、export/import、runbook 與 no-go condition
• 2026-05-21 SQLite Backup Restore Drill SQLite .backup、VACUUM INTO、restore validation、sidecar file handling 與 RPO / RTO note 的操作說明
• 2026-05-21 SQLite D1 / Turso / libSQL Comparison Cloudflare D1、Turso、libSQL 與 local SQLite 在 edge、replication、consistency、migration 與 vendor boundary 的比較
• 2026-05-21 SQLite D1 / Turso Preview Lab SQLite local DB 匯出到 Cloudflare D1 或 Turso preview environment 的 compatibility、latency 與 rollback 操作說明
• 2026-05-21 SQLite file lifecycle 與 backup boundary 把 SQLite 單檔案正式狀態拆成 WAL、backup API、restore drill、corruption recovery 與操作責任邊界
• 2026-05-21 SQLite Litestream / LiteFS Replication Litestream、LiteFS、SQLite backup replication、read replica、failover 與 restore route
• 2026-05-21 SQLite Local File Quickstart SQLite local .db file、schema、seed data、PRAGMA baseline、query sample 與 cleanup 的操作說明
• 2026-05-21 SQLite Local-first Sync Boundary SQLite local-first app、multi-device sync、server authority、conflict resolution、delete propagation 與 offline-first trade-off
• 2026-05-21 SQLite Migration Fixture Lab SQLite user_version、table rebuild migration、fixture snapshot、rollback note 與 CI evidence 的操作說明
• 2026-05-21 SQLite Mobile / Desktop Embedded Store SQLite 在 mobile、desktop、CLI、browser profile 與 embedded device 中承擔 local formal state 的資料責任、backup、privacy 與 sync boundary
• 2026-05-21 SQLite Observability and Runbook SQLite production runbook、backup evidence、WAL growth、busy errors、disk usage、restore drill 與 incident route
• 2026-05-21 SQLite PRAGMA Tuning and Performance SQLite journal_mode、synchronous、busy_timeout、wal_autocheckpoint、cache_size、mmap_size、auto_vacuum 與 performance evidence 的操作判準
• 2026-05-21 SQLite Schema Migration and Versioning SQLite schema migration、user_version、table rebuild、ALTER TABLE 限制、app release compatibility 與 migration evidence
• 2026-05-21 SQLite SQL Dialect and Index Limits SQLite type affinity、NULL / date handling、constraint、index、query planner 與 PostgreSQL / MySQL 差異
• 2026-05-21 SQLite Teaching Structure SQLite 服務章節群的大綱：從 embedded formal state、WAL、backup、test fixture、local-first、edge SQLite 到遷移路由
• 2026-05-21 SQLite Test Fixture Best Practice SQLite 作為 test fixture、repository contract test、production dialect gap、seed data、fixture snapshot 與 CI evidence 的操作判準
• 2026-05-21 SQLite to D1 / Turso Migration SQLite 轉向 Cloudflare D1、Turso / libSQL 的 edge driver、compatibility audit、data movement 與 rollback
• 2026-05-21 SQLite to PostgreSQL Migration SQLite 升級到 PostgreSQL 的 driver、schema diff、data copy、dual run、cutover、rollback 與 cleanup
• 2026-05-21 SQLite WAL Busy Reproduction SQLite long transaction、SQLITE_BUSY、busy_timeout、checkpoint growth 與 writer queue 的操作說明
• 2026-05-21 SQLite WAL Concurrency and Locking SQLite WAL mode 如何降低 reader / writer 衝突、保留 single writer boundary，並用 SQLITE_BUSY、WAL growth、checkpoint 訊號判斷 production 上限
• 2026-05-20 資料庫 Vendor 文章撰寫規格 把 PostgreSQL 與 MySQL batch 的正文經驗整理成資料庫 vendor overview、deep article 與 migration playbook 的撰寫規格