本文是跨 vendor migration playbook、cross-link 到 PostgreSQL（self-managed source）跟 Aurora（cloud-managed target）。跟前兩篇 migration（Splunk → Elastic 高 schema 差 / Redis → DragonflyDB drop-in）對照、本篇是 middle ground：wire protocol drop-in、但 operational model 重設計。每階段切換用 migration gate 把關。

為什麼遷：operational cost / HA / DR 三條 driver

反向 driver（Aurora → self-managed）也存在 — 主要是 cost 在 10TB+ 規模時 Aurora 反而更貴、或 需要 PostgreSQL extension Aurora 不支援（pg_partman / pg_repack / TimescaleDB 等）。

結構：protocol 相容 + operational phased 的混合

跟前兩篇對照、Aurora migration 結構是 protocol drop-in（application 不改 SQL）+ operational redesign（HA / backup / monitoring 全換）：

Hypothesis 驗證：migration playbook 結構由 最大差異維度 決定 — Splunk → Elastic 是 schema 差導向 phased、Aurora migration 是 operational 差導向局部 phased。

Operational redesign 對位

跟 self-managed PostgreSQL 比、Aurora 的 operational 模型差異：

每一條 operational concept 都需要 migration plan、application code 不變但 運維知識體系全換。

Migration 流程：3 phase operational + drop-in cutover

Phase 0：Pre-migration audit（1-2 週）

1. Extension 清單對位：

1SELECT extname, extversion FROM pg_extension;
2-- 對照 Aurora supported extensions list
3-- 不支援的（pg_repack / pg_partman 部分 / TimescaleDB / Citus）需替代方案

2. Custom config 清單：

1SELECT name, setting FROM pg_settings WHERE source != 'default';
2-- 對照 Aurora Parameter Group 可調項目

3. Capacity 評估：

• 當前 IOPS / connection / storage / WAL rate
• 對應 Aurora instance class（db.r6g.large to db.r6g.32xlarge）
• 估算 cost（vCPU + IOPS + storage + backup retention）

4. Application connection pool audit：

• PgBouncer 配置是否能直接搬到 RDS Proxy
• Connection string + IAM 認證準備

Phase 1：Operational infrastructure 準備（2-3 週）

1. 建 Aurora cluster（Terraform / CloudFormation）
2. 設 Parameter Group、對位 self-managed 配置
3. 設 Security Group + IAM role
4. 設 RDS Proxy（推薦、connection 集中管理）
5. CloudWatch alert + Performance Insights baseline
6. Backup retention + PITR window 設定

Phase 2：Data migration（取決於 dataset 大小）

兩條路：

路線 A：AWS DMS（推薦中等規模 < 5TB）

1self-managed Postgres ──(DMS)──→ Aurora
2                         |
3                  full load + CDC continuous

• DMS task 設 Full Load + Ongoing Replication
• 跑 full load 估算（100GB ~ 1-3 小時依 instance class）
• CDC 持續直到 cutover

路線 B：Logical replication（推薦 5TB+ 或要精準控制）

1-- Source：建 publication
2CREATE PUBLICATION migrate_pub FOR ALL TABLES;
3
4-- Aurora：建 subscription
5CREATE SUBSCRIPTION migrate_sub
6  CONNECTION 'host=<source> dbname=<db> user=<replicator>'
7  PUBLICATION migrate_pub;

• Initial COPY 跑完後 streaming
• 詳見 Logical Replication + Debezium

Phase 3：Cutover 跟 verification

11. Application 端設 maintenance mode（block writes）
22. 等 replication lag → 0
33. 確認 Aurora 端 row count + checksum 對齊
44. Application connection string 切到 Aurora endpoint
55. 解除 maintenance mode
66. Self-managed 端 read-only 保留 1-2 週 standby

Cutover window 視 dataset 大小：

• < 100GB：1-2 小時
• 100GB - 1TB：2-4 小時
• 1TB+：考慮 zero-downtime cutover via blue-green deployment

Production 故障演練

Case 1：Extension 不支援、application 直接壞

徵兆：cutover 後 application 某些 query 報 extension "pg_repack" not available、batch job 壞。

根因：Phase 0 audit 漏掉 application 用 pg_repack 做 maintenance；Aurora 不支援、self-managed 端的 cron job 改不過去。

修法：

1. Pre-migration audit 必做：SELECT extname FROM pg_extension 對照 Aurora extension whitelist
2. 替代方案：
   • pg_repack → Aurora 自家 vacuum + storage auto-resize
   • TimescaleDB → 改 declarative partitioning 或換 Timestream
   • Citus → 評估保留 self-managed 或重設計 schema
3. 退役策略：Extension 是 application 必要的、評估暫不遷或選 alternative cloud（如 AlloyDB / Citus on Azure）

Case 2：Replication slot 不直通

徵兆：self-managed 端有 Debezium CDC 接 application 事件、cutover 後 CDC pipeline 直接壞、Kafka 端訊息斷流。

根因：Aurora 對 logical replication slot 有限制 — 不直接支援 external consumer（如 Debezium）讀 slot；要走 RDS Database Events 或 DMS CDC。

修法：

1. Pre-migration audit：列所有 logical consumer（Debezium / Kafka Connect / 自家 CDC）
2. 替代方案：
   • DMS CDC 取代 Debezium（Aurora 原生支援）
   • 評估 RDS Database Activity Streams（newer feature）
   • 重設計 CDC：application 寫 outbox 表、Aurora trigger 發 SNS → Lambda → Kafka
3. 接受代價：CDC pipeline 重建是 2-4 週工作、納入 migration scope

Case 3：Autovacuum 行為跟 self-managed 不同

徵兆：cutover 後幾天、特定 hot table 的 bloat 數據異常、application 端 query latency p99 漲；CloudWatch Performance Insights 顯示 autovacuum 跑頻率比 self-managed 端高 3 倍。

根因：Aurora 預設 Parameter Group 的 autovacuum 配置跟 self-managed 不同 — autovacuum_vacuum_cost_limit 預設更低、vacuum_scale_factor 更激進；shared storage 上 vacuum 行為不一樣。

修法：

1. Parameter Group 對位：把 self-managed autovacuum tuning 配置複製到 Aurora Parameter Group
2. per-table tuning：hot table 的 ALTER TABLE SET (autovacuum_*) 可遷過去
3. 接受差異：Aurora storage 設計讓 vacuum 不一定要跟 self-managed 同 cadence、SRE 心智模型要調

Case 4：IAM 認證強制、application 端改 connection logic

徵兆：production 切到 Aurora 後、application 仍用 password authentication、SOC team 要求改 IAM 認證（compliance）；application 連線 logic 大改、token rotation 邏輯也要加。

根因：self-managed 端用固定 username/password、Aurora 推薦（部分情境強制）IAM authentication；token 15 分鐘輪換、application 必須改連線 SDK。

修法：

1. Migration scope 內包含：authentication migration 是必要工作、不能事後補
2. SDK 整合：用 AWS SDK + RDS Proxy 抽象 token rotation、application 不直接管 token
3. Hybrid 期間：保留 password auth 直到 application 全切 IAM、再 disable password auth

Case 5：Cost model 預估錯、月底帳單炸

徵兆：第一個月 Aurora 帳單比預估高 50-80%；IOPS / backup storage / I/O cost 都比預期多。

根因：Aurora pricing 三層（compute instance / storage / I/O）—

• Storage：actual data + backup × retention
• I/O：每個 read / write block 都計費（self-managed 不算）
• Backup：超過 backup retention 部分 charged as snapshot storage

self-managed 端習慣 fixed EC2 + EBS cost、Aurora I/O-based 計費對 high-IOPS workload 衝擊大。

修法：

1. Pre-migration cost estimate：用 self-managed pg_stat_database 估 I/O 量、套 Aurora pricing calc
2. I/O optimization：開 Aurora I/O-Optimized storage class（fixed monthly + 不算 I/O）、適合 high-IOPS workload
3. Backup retention 控制：不要 default 35 天、依 compliance 調整（7-14 天通常夠）
4. Reserved Instance：穩定 workload 預付 1-3 年、省 30-40%

Capacity / cost 對照

判讀：< 10TB workload Aurora 平攤 operational cost 後仍便宜；50TB+ workload Aurora cost 顯著高、要 reserved + I/O-Optimized 才有競爭力。

整合 / 下一步

跟 Patroni HA 對位

Patroni 在 Aurora migration 後 退役 — Aurora 自家 failover 取代；但 SRE 心智模型要調：

• Patroni 的 pg_rewind 概念不存在（shared storage）
• Patroni 的 synchronous_commit 行為 Aurora 隱藏在 storage layer
• Aurora 跨 region 用 Global Database、不是 Patroni cross-region setup

跟 PITR 對位

self-managed PITR rebuild 工作量大、Aurora PITR 是 native API call：

1aws rds restore-db-cluster-to-point-in-time \
2  --source-db-cluster-identifier myapp-prod \
3  --db-cluster-identifier myapp-prod-restored \
4  --restore-to-time 2026-05-19T14:30:00Z

完全不需要 base backup + WAL replay 思維、storage layer 自動處理。

跟 PgBouncer → RDS Proxy

PgBouncer 多數情境可換 RDS Proxy：

• transaction pooling 等效
• IAM authentication 整合
• Connection pinning（Lambda / serverless workload）
• 限制：RDS Proxy 對某些 PG 14+ feature 仍 catching up、prepared statements 行為差異

下一步議題

• Aurora Serverless v2 評估：variable workload 適合、steady workload 反而貴
• Babelfish 評估：跑 SQL Server protocol on Aurora（多 source 遷移到 Aurora）
• Cross-region DR：Aurora Global Database vs self-managed cross-region streaming + Patroni

相關連結

• Source vendor：PostgreSQL
• Target vendor：Aurora
• 平行 migration playbook：Splunk → Elastic Security / Redis → DragonflyDB
• Aurora family 內進一步遷移：→ Aurora DSQL（從 Aurora PG 升 DSQL active-active distributed、Type E paradigm shift）
• 平行 deep article：Patroni HA / PITR + WAL Archiving / Logical Replication + Debezium
• Methodology：Vendor 深度技術文章的寫作方法論

本文是跨 vendor migration playbook、cross-link 到 PostgreSQL（source）跟 Aurora（DSQL 也屬 Aurora family、但 paradigm 不同）。跟 migrate-to-aurora（PG → Aurora PG、protocol drop-in + operational redesign）跟 migrate-to-cockroachdb（PG → CRDB、Type E paradigm shift）對照、本篇是 Aurora 內 PG → DSQL 的 paradigm shift。每階段切換用 migration gate 把關。

時間錨點：Aurora DSQL 在 2024-12 re:Invent preview、2025-05-27 GA。本文 vendor claim 以 2025-2026 公開狀態為準、實際 migration 前請以 AWS docs 為準（feature 持續演進中）。

為什麼遷：Global Write / Operational Zero-touch / Region Resiliency 三條 driver

PG → DSQL 不是「自然演進」、是 application 需求超出 single-primary 模型 時的 paradigm 換軌。三條典型 driver 各自對應一種 application 約束、不是「三選一」、而是「至少其中一條剛性、其他兩條是 bonus」：

反向 driver（DSQL → Aurora PG）也存在：

• 需要 PG extension（pgvector / TimescaleDB / PostGIS / pg_repack）— DSQL 不支援
• Cost：DSQL 比 Aurora PG 貴 2-5x（依 region 數量）
• Single-region OLTP 不需 distributed transaction 的 overhead

結構：Protocol Drop-in + Paradigm Shift

DSQL 是 PG wire-compatible（用 psql 連得上）、但內部是 distributed SQL engine：

Paradigm shift 的核心：

1. Transaction semantic：DSQL 用 OCC（Optimistic Concurrency Control）+ strong snapshot isolation、跟 PG 預設 read committed / repeatable read snapshot 不同 — 同 row 有 concurrent write 時、commit 階段才偵測衝突 + abort、application 要 handle 40001 serialization_failure
2. No extension：PostGIS / pgvector / TimescaleDB / pg_partman 都不能用、依賴這些 feature 的 application 要拆出去
3. No connection pool stateful：DSQL 內建 connection pool、application 不能依賴 session state（temp table / prepared statement / advisory lock）

Schema gap：PG 對 DSQL 限制

DSQL 是 PG-compatible subset、有幾類功能不支援：

Migration 必做 schema audit：

 1-- 找所有 extension 依賴
 2SELECT * FROM pg_extension;
 3
 4-- 找 materialized view
 5SELECT schemaname, matviewname FROM pg_matviews;
 6
 7-- 找 sequence
 8SELECT * FROM pg_sequences;
 9
10-- 找 FDW
11SELECT * FROM pg_foreign_server;
12
13-- 找 trigger
14SELECT * FROM pg_trigger WHERE NOT tgisinternal;

任何項目命中、都是 migration blocker。

Operational Redesign

跟 self-managed PG 或 Aurora PG 比、DSQL operational model 大幅簡化但語意不同：

Migration 流程：Type E Phased Plan

Type E paradigm shift 的 phased plan、跟 migrate-to-cockroachdb 結構類似：

Phase 1：Schema / Application Audit

• 跑 schema audit（extension / MV / FDW / sequence / trigger）
• 識別 application 哪些 query / transaction pattern 需重設計
• 估算 能直接遷的 % vs 需重寫的 %、典型 60-80% / 20-40%

Phase 2：Application 改造（不上 DSQL、先在 PG 跑）

• 加 transaction retry middleware（攔截 40001、exponential backoff）
• 用 UUID 替代 serial / bigserial
• 移除依賴 LISTEN/NOTIFY 的功能（改 SQS / EventBridge）
• 移除 materialized view（改 application-side cache 或 incremental ETL）
• Stored procedure 改 application code
• 在 PG 上跑 staging、確認新 application code 還對

Phase 3：DSQL Cluster 建立 + Schema 遷

• DSQL cluster create
• DDL apply（subset of PG schema、無 extension）
• DMS（Database Migration Service）initial load + ongoing replication
• 兩邊跑 shadow traffic、比對 query 結果

Phase 4：Cutover

• Application 切 connection string 到 DSQL
• 保留 PG read-only 一週、出狀況 rollback
• Monitor 40001 retry rate、scaling event 行為

Phase 5：多 region 拓展（如適用）

• 加第二 region endpoint
• Application 改 multi-region routing（latency-based）
• Test region failure / network partition 行為

5 個 Production 踩雷

Case 1：Transaction Retry 沒處理

情境：PG 上「兩個 transaction 都 update 同 row」走 lock + wait；DSQL 同情境一個會收 40001 serialization_failure、application 沒 catch、user 看到 500 error。

修法：

• DAO 層加 retry middleware：catch 40001 + exponential backoff（jitter）
• Retry 上限 3-5 次、超過回 4xx 給 user
• Transaction 內不要做 side effect（API call / message send）、retry 會重做

1def with_retry(fn, max_attempts=5):
2    for attempt in range(max_attempts):
3        try:
4            return fn()
5        except SerializationError:
6            if attempt == max_attempts - 1:
7                raise
8            time.sleep((2 ** attempt) * 0.05 + random.random() * 0.05)

Case 2：Extension 缺位、Feature 整段掉

情境：production PG 用 pgvector 做 RAG search、PostGIS 做 store locator、TimescaleDB 做 metrics — 切 DSQL 後三 feature 全沒。

修法：

• 不要直接遷、評估 which extension is load-bearing
• pgvector → 外掛 Pinecone / Weaviate 或保留 PG 跑 vector workload
• PostGIS → 保留 PG 跑 GIS workload
• TimescaleDB → 切 Amazon Timestream 或保留 PG
• DSQL 只放 不依賴 extension 的 transactional core

實務常見拓撲：DSQL 跑 transactional core、附 PG（vector） + PG（GIS） + Timestream（metrics）。

Case 3：Sequence 高吞吐撞 Coordination Overhead

情境：SERIAL / GENERATED AS IDENTITY PK 在 DSQL 用、insert 量 1000+/s 時 sequence nextval 變成 bottleneck、insert latency 從 5ms 跳到 80-100ms+。

DSQL 有支援 sequence、但不是「local atomic counter」、是分散式 counter — 每次 nextval 需跨 region coordination 保證唯一性。低吞吐 OK、高吞吐撞牆。

修法：

• 高吞吐表 PK 換 UUID v7（time-sortable、無 coordination）：gen_random_uuid() 或 application-side UUID v7 library
• 或 application-side ULID（time-sortable、12-byte 緊湊）
• 完全避免依賴「連續 integer PK」的 application 邏輯（reporting / paging 改用 ORDER BY created_at, id）

1-- 換 UUID PK
2CREATE TABLE orders (
3    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
4    ...
5);

低吞吐表（settings / config）保留 sequence OK；high-volume transactional 表（orders / events）建議 UUID。

Case 4：Aurora PG 直升 DSQL 想當 in-place

情境：team 以為「Aurora PG 跟 Aurora DSQL 都是 Aurora、應該能直升」、申請 cluster modify、發現完全是兩個 service。

修法：

• 不是 in-place upgrade、是 full migration（DMS + cutover）
• 把 DSQL 當完全新的 cluster type、走 Phase 1-4 完整流程
• Aurora PG → Aurora DSQL 不比 PG → CRDB 容易、wire-compatible 只解 application connect 問題、不解 schema / paradigm 差異

Case 5：Region Failover Semantic

情境：team 以為「DSQL multi-region 等於高可用」、設計時假設「整 region 掛還是能寫」、實測發現「網絡分割時 DSQL 走 quorum、可能 reject write」。

DSQL 是 strong consistency 多 region、CAP 取 CP（不是 AP）— network partition 時部分 region 會拒絕 write、不是「永遠可寫」。

修法：

• 設計 application 要 handle write reject（partition recovery 後 retry）
• 不要把 DSQL 當「永遠可寫」的 cache 或 queue 用
• 真要 AP 行為、用 DynamoDB（global table）

Capacity 規劃

DSQL 計費跟 Aurora PG 差很多：

實務 cost：Aurora PG db.r6g.4xlarge multi-AZ 月 ~$2000 → DSQL 同 workload ~$5000-10000（依 region 數）。

何時 DSQL cost 划算：

• 多 region active-active 需求剛性（不是 nice-to-have）
• Operational FTE 節省超過 cost 差
• Burst workload（DSQL 自動 scale、Aurora PG 預配置 idle 期浪費）

跟既有 Migration Playbook 對比

Aurora DSQL vs CockroachDB 選擇：

選 DSQL：已綁 AWS、不想管基礎設施、需 PG semantic。 選 CRDB：跨雲、有自管 SRE、需要 fine-grained control。

相關連結

• migrate-to-aurora：Aurora PG 對比（Type C）
• migrate-to-cockroachdb：CRDB 對比（Type E）
• extension-ecosystem：DSQL 不支援的 extension
• connection-scaling：DSQL 內建 pool 跟 PgBouncer 對比

下一步

• 看 Aurora overview 認識 Aurora family
• 看 migrate-to-cockroachdb 對比另一個 Type E migration
• 回 PostgreSQL overview 看全圖