Tarragon

"Deep-Article"

• 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-18 Cloudflare Page Shield：用 CSP + SRI + script monitoring 防 client-side supply chain Page Shield 三層防禦（CSP / SRI / script monitoring）對應 Magecart / formjacking / skimmer / 第三方 SDK 注入的不同 attack pattern、Cloudflare dashboard + API 配置、四個 production 踩雷（inline script 漏 / dynamic loader / CSP report 噪音 / SRI hash mismatch）、跟 dev workflow + WAF 整合
• 2026-05-18 HashiCorp Vault Dynamic Credential：lease 治理跟 application 整合的實作層 Vault database secrets engine 怎麼配、application 怎麼 renew lease、production 五大踩雷（lease 過期 race、DB max_connections 撞牆、Vault sealed、token expire、scope 過寬）、容量規劃跟 vault-agent injector 整合
• 2026-05-18 Kubernetes Graceful Shutdown：termination 序列跟你以為的不一樣 K8s pod termination 五步序列、preStop / SIGTERM / terminationGracePeriodSeconds 的真實時序、5 個 production 踩雷（500 期間 502、connection drain race、init container 重啟、StatefulSet 串行終止、Job 不 graceful）、跟 service mesh / readiness probe 整合
• 2026-05-18 Splunk Risk-Based Alerting：從 alert per rule 到 score-aggregated notable Splunk Enterprise Security 的 RBA 方法論：risk score / modifier / notable 三層 model、ES 配置 step-by-step、tuning playbook（false positive / score inflation / threshold drift / decay）、capacity 成本、跟 SOAR + case management 整合
• 2026-06-16 AWS ElastiCache 的責任邊界：managed 接手了什麼、又默默留下什麼 ElastiCache 把 failover、patching、snapshot、跨 AZ 複製接走，但 cache stampede、client 重連、key 設計、eviction policy 還是你的事。本文用 shared responsibility 拆解 managed 的真實邊界、展開 engine 選擇與 cluster mode 配置、5 個把『以為 AWS 全包』寫成事故的 production 踩坑，以及 ElastiCache 到 MemoryDB 的 durability 邊界
• 2026-06-16 Caffeine + Redis 兩層 cache：搭起來很容易，跨實例失效才是全部的問題 L1 Caffeine（process-local）+ L2 Redis（共享）的兩層 cache 程式碼三十行就寫完，但每個 JVM 實例有自己的 L1 副本、一個實例更新不會通知其他實例——跨實例 invalidation 才是這個架構的全部難度。本文展開兩層讀寫路徑、用 Redis pub/sub 廣播失效、5 個把 L1 stale 與 GC 寫成事故的 production 踩坑，以及哪些資料適合放 L1
• 2026-06-16 DragonflyDB shared-nothing 多核架構：用 scale-up 取代 Redis Cluster Redis 要靠 Cluster 分片才能用滿一台多核機器，DragonflyDB 賭的是相反方向——單一進程 thread-per-core、shared-nothing、把單機推到 Redis 要好幾個 shard 才達到的規模。本文展開 thread-per-core 與 dashtable 的架構、fork-less snapshot、5 個把架構假設寫成 production 事故的踩坑，以及 scale-up 撞牆該回 Cluster 的邊界
• 2026-06-16 Google Pub/Sub push vs pull：不是實作偏好，是下游容量的判讀 Pub/Sub 的 push 與 pull subscription 常被當成實作偏好二選一，但它其實是一個容量判讀：push 把流量瞬間打到 endpoint，pull 讓 consumer 自己節流。下游有 RPS 限制就只能 pull。本文展開 subscription 模型、ack deadline、flow control 與 dead-letter topic，5 個把 push/pull 與 ack deadline 寫成下游打爆與重投的 production 踩坑
• 2026-06-16 Kafka Consumer Group Rebalance 與 Lag 診斷：從 protocol 到故障演練 Kafka consumer group 的 rebalance protocol（eager vs cooperative incremental）、static group membership、session.timeout.ms / max.poll.interval.ms / heartbeat.interval.ms 三個 timeout 的職責、consumer lag 均勻分布 vs 集中單一 partition 的診斷路徑、rebalance storm 成因與對策；含 kafka-consumer-groups.sh 實機驗證輸出與 4 個 production 故障演練
• 2026-06-16 KeyDB active-active 多主複製：last-write-wins 會默默吃掉哪一筆寫入 KeyDB 的 active-active 讓兩個 master 都能寫、互相同步，聽起來解決了跨區寫入的所有問題——直到兩邊同時寫同一個 key，last-write-wins 默默丟掉其中一筆。本文展開 active-active 的複製機制與衝突語意、實機驗證雙向同步、5 個把多主複製寫成資料遺失與迴圈的 production 踩坑，以及哪些資料能放 active-active、哪些不能的邊界
• 2026-06-16 Memcached slab allocator 與記憶體經濟學：明明有記憶體卻在 evict Memcached 用 slab allocator 預切記憶體成固定大小的 chunk，這讓它永不碎片化、卻會在還有大量空閒記憶體時就開始淘汰——slab calcification。本文展開 slab class、growth_factor、page 分配的會計模型、5 個把 slab 機制寫成記憶體浪費與淘汰事故的 production 踩坑，以及純 KV 邊界與多執行緒擴展的判讀
• 2026-06-16 NATS core 到 JetStream：fire-and-forget 在哪裡不夠、跨過去要付什麼 Core NATS 的 fire-and-forget 在 consumer 重啟或 rolling deploy 時掉訊息——這不是 bug、是設計。需要訊息不丟就跨進 JetStream（persistence + at-least-once + redelivery）。本文展開 core 與 JetStream 的邊界、stream 與 consumer 的求值模型、實機驗證的 durable pull consumer、5 個把 JetStream consumer 寫成丟訊息與重投風暴的 production 踩坑
• 2026-06-16 Pub/Sub Ordering Key、Dead-Letter Topic 與 Schema Enforcement：三道交付治理 Pub/Sub overview 之下的 implementation-layer deep article — 把 ordering key 的有序代價、dead-letter topic 的 poison message 隔離、schema enforcement 的契約守門三件事寫到可操作：subscription 是 first-class、ackDeadline 與 extension、push vs pull vs streaming pull + flow control、Avro / Protobuf schema、Pub/Sub Lite 與標準版差異、BigQuery / Cloud Storage subscription，含 5 個 production 故障演練（ordering 限流 / ack deadline 太短重投 / DLT max delivery attempts / push 500 retry storm / schema 擋下不相容 publish）
• 2026-06-16 RabbitMQ DLQ 與分層 retry：別把失敗訊息 requeue 回隊首 RabbitMQ 處理失敗訊息最常見的錯是直接 requeue 回原隊列——它回到隊首、反覆失敗、把後面的訊息全卡住（head-of-line blocking）。正解是用 dead-letter exchange + TTL 組出 work → delay → DLQ 的分層 escalation。本文展開 DLX 求值模型、實機驗證的三層拓樸、5 個把 retry 寫成無限迴圈與隊列阻塞的 production 踩坑，以及 retry 拓樸的容量邊界
• 2026-06-16 Valkey 相容性驗證與 io-threads 調校：drop-in 切換與多執行緒的實機判讀 Valkey 跟 Redis 100% 相容這句話要怎麼驗證、切換才敢上線。本文用 INFO server 的雙版本回報拆解相容性的真實邊界、展開 Valkey 8 的 io-threads 多執行緒調校、5 個把 drop-in 切換或執行緒配置寫成事故的 production 踩坑，以及相容性撞牆該怎麼判斷的邊界
• 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-06-16 AWS SQS：Visibility timeout、long polling 與 Lambda event source 的成本與失敗形狀 SQS deep article：visibility timeout 對齊 consumer 處理時間（ChangeMessageVisibility）、long vs short polling 的 cost 取捨（WaitTimeSeconds）、SQS + Lambda event source mapping（batch size / batch window / 並行 ramp-up）、DLQ + redrive policy（maxReceiveCount）、message size 與 extended client、per-request cost 模型；含 5 個 production 故障演練（VT < 處理時間 redelivery、polling 設定省成本、Lambda 部分失敗整批重投、DLQ maxReceiveCount、FIFO 吞吐上限）
• 2026-06-16 Kafka Replication、ISR 與 exactly-once：從 acks 到端到端不重不漏 Kafka 的可靠性由 replication 與 ISR 決定寫入承諾、由 producer idempotence 與 transaction 決定處理語義。本文涵蓋 acks=0/1/all 取捨、min.insync.replicas 與 ISR shrink/expand 的真實行為、enable.idempotence 去重、Kafka transaction + read_committed 隔離、以及端到端 exactly-once 的邊界與成本；含 3-broker 叢集停 broker 觀察 ISR 收縮到低於 min.insync 後 acks=all 被拒的實機演練。
• 2026-06-16 NATS JetStream 設計與 supercluster / leaf node：stream、consumer、跨區拓樸與多租戶 NATS JetStream 的 implementation-layer deep article：stream 設計（storage / retention / discard / 容量上限）、consumer 設計（pull/push、explicit ack、AckWait、MaxDeliver、replay）、Cluster Raft / Supercluster gateway / Leaf node edge 三層拓樸、subject-based ACL 多租戶；含 4 個 production 故障演練（AckWait 太短重投、discard policy 選錯丟訊息、leaf node 斷線重連、stream replica 失去 quorum）。
• 2026-06-16 Redis Streams XCLAIM / PEL 失敗接管與 Cluster 影響 Redis Streams 把可靠性責任放在 application 層：PEL 記錄已投遞未 ack 的訊息、XCLAIM / XAUTOCLAIM 是 consumer crash 後唯一的接管機制。本文用實機輸出走 PEL / XACK / XCLAIM / XAUTOCLAIM / min-idle-time 機制、5 個故障演練（PEL 卡死、搶單、MAXLEN 修掉未 ack 訊息、Cluster 單 shard 限制、failover 後 PEL 狀態），跟 MAXLEN / XTRIM retention 取捨。
• 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-06-16 Kafka Retention 與 Tiered Storage：保留策略、log compaction 與冷熱分層 Kafka 的保留策略決定 replay window 與儲存成本：retention.ms / retention.bytes 控制刪除邊界、cleanup.policy 切換 delete 與 compact、log compaction 用最新值取代歷史、tiered storage 把冷資料卸到 S3 讓 broker 容量與保留期解耦。本文涵蓋配置實機驗證、4 個故障演練（replay 失敗 / compaction 不回收磁碟 / cold tier 讀延遲 / retention.bytes 提早刪）、容量成本與整合路由。
• 2026-06-16 RabbitMQ Queue Type 選型：Classic、Quorum、Stream 的責任邊界與容量取捨 RabbitMQ 3.x 三種 queue type 的選型 deep article — classic queue（mirrored 已 deprecated）、quorum queue（Raft 一致性、取代 mirrored）、stream（3.9+ append-only log、可重複消費）。涵蓋三種模型在 throughput / retention / replay / 記憶體成本的判讀、宣告語意差異（實機驗證）、4 個 production 故障演練（mirrored 網路放大 / quorum loss / stream retention 超量 / classic→quorum in-flight message），與容量規劃。
• 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-05-19 Redis Cluster Re-sharding：source = target，但 topology 重劃的 5 段流程 Redis cluster re-sharding 是 5 type migration 漏類實證 — source / target 同 cluster、無 schema / paradigm 差、但 16384 slot 重分配是核心；本文涵蓋 4 種 re-sharding driver、slot migration 機制、redis-cli --cluster rebalance / reshard 工具、5 個 production 踩雷（cluster busy / replica lag / client cache stale / cross-slot transaction / monitor gap）
• 2026-06-16 Kafka Schema Registry 與 schema 演進：wire format、compatibility level 與安全演進規則 Kafka 跨系統事件總線的 schema 治理 implementation deep article — Schema Registry（Confluent / Apicurio）角色、Avro / Protobuf / JSON Schema 取捨、subject naming strategy、backward / forward / full / none 及其 transitive 版本、producer 帶 schema ID 的 5-byte wire format、加欄位帶 default 與刪欄位分步的安全演進規則；含 4 個 production 故障演練與實機驗證的 REST API 回應
• 2026-06-16 RabbitMQ Network Partition 與 Cluster 一致性：腦裂下要保誰 RabbitMQ Erlang cluster 在 network partition 下的行為與處置 — disc/ram node 拓樸、cluster_partition_handling 三策略（ignore / pause_minority / autoheal）的可用性與一致性取捨、腦裂偵測機制、quorum queue 在失去 quorum 時的 Raft 行為。含 3-node OrbStack 實機演練（pause_minority 暫停少數派、quorum queue 失去 quorum 後寫入阻塞、classic queue 同情境續寫對照）。
• 2026-06-16 Redis 記憶體與淘汰調校：maxmemory-policy、LFU 與碎片化的實戰判讀 Redis 的記憶體是一條會在半夜爆掉的曲線：maxmemory 設多少、policy 選 LRU 還 LFU、碎片化什麼時候開始吃掉 30% RAM、OOM 時 noeviction 怎麼讓寫入全部失敗。本文展開 Redis 記憶體會計模型、eviction policy 的選型判讀、5 個把記憶體配置寫成 production 事故的踩坑，以及單機記憶體撞牆後該往 cluster 還是 DragonflyDB 走的邊界
• 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 Kafka Multi-tenant 治理：quota 限流、ACL 授權與 topic 生命週期 單一 Kafka 叢集承載多團隊時、quota 把頻寬與 request 容量切給每個租戶、ACL 把寫入與讀取權限綁到 principal、topic 命名規範劃出 ownership 邊界、生命週期治理回收死 topic 釋放 metadata 壓力。本文涵蓋 producer_byte_rate / consumer_byte_rate / request_percentage 三類 quota 與 user / client-id / 組合三種套用層級、StandardAuthorizer 的 principal × resource × operation × host 授權模型、prefixed ACL 的 tenant 隔離、TopicGC 式的死 topic 回收、以及四個 production 故障演練（單租戶暴衝吃滿頻寬、ACL 過鬆過緊、topic 數量爆炸壓垮 controller、unused topic 未回收）
• 2026-06-16 Redis 持久化與 fork latency：AOF、RDB 與那一次卡住整個 cluster 的 fork Redis 的 RDB save 與 AOF rewrite 都靠一次 fork()，而 fork 在大記憶體實例上會凍結主執行緒數百毫秒、複製分頁讓記憶體逼近翻倍。本文展開 AOF / RDB 的機制與 fsync 取捨、copy-on-write 的記憶體放大、5 個把持久化寫成延遲尖峰與資料遺失的 production 踩坑，以及 cache 場景到底要不要持久化的邊界
• 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-06-16 Redis Sentinel 與 failover 時序：從 master 死掉到 client 重連的每一段 Redis Sentinel 的 failover 不是一個瞬間動作，是 down 偵測 → quorum 確認 → 選主 → 提升 → 配置廣播 → client 重連的一條時序鏈，每一段都有自己的延遲與失敗模式。本文展開 Sentinel 的判定模型與這條時序、5 個讓 failover 卡住或丟資料的 production 踩坑，以及 Sentinel 撐不住該往 Cluster 或 managed 走的邊界
• 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-06-16 Redis 連線與 pipeline：RTT 稅、連線池與一次往返打包多命令 Redis 單命令通常微秒級執行，但 application 端量到的延遲是毫秒級——差距全在網路往返（RTT）。pipelining 的本質不是『批次發命令』，是把 N 次 RTT 壓成 1 次。本文展開 RTT 會計、連線池配置、pipeline 與 MULTI 的差異、5 個把連線與往返寫成延遲與正確性問題的 production 踩坑，以及連線模型撞牆的邊界
• 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 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 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 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 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-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 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-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-21 SQLite file lifecycle 與 backup boundary 把 SQLite 單檔案正式狀態拆成 WAL、backup API、restore drill、corruption recovery 與操作責任邊界
• 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 Mobile / Desktop Embedded Store SQLite 在 mobile、desktop、CLI、browser profile 與 embedded device 中承擔 local formal state 的資料責任、backup、privacy 與 sync boundary
• 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 Test Fixture Best Practice SQLite 作為 test fixture、repository contract test、production dialect gap、seed data、fixture snapshot 與 CI evidence 的操作判準
• 2026-05-21 SQLite WAL Concurrency and Locking SQLite WAL mode 如何降低 reader / writer 衝突、保留 single writer boundary，並用 SQLITE_BUSY、WAL growth、checkpoint 訊號判斷 production 上限