本文是跨 vendor migration playbook、cross-link 到 Vitess sharding 跟 PlanetScale。走 Migration playbook methodology Type C operational hybrid 結構。

這條 migration 跟 → Aurora MySQL 相似（self-managed → managed），但 target 是 Vitess-native managed、保留 sharding 能力。同時加上 → PlanetScale from self-managed MySQL 的 branch workflow paradigm。

對 已花心力建 Vitess team 但 ops cost 太大 的 org 來說、這條 migration 比 Vitess → distributed SQL 風險低、保留 sharding investment。

為什麼是 Type C operational hybrid（不是 Type A phased translation 或 Type E paradigm shift）

跑 6 維 diff dimension audit：

Operational = High（其他 Low / Medium） → Type C operational hybrid。Branch workflow 是 Medium paradigm shift 但不是 dominant — 主要工作量在 operational ownership 轉移。

跟 自管 MySQL → PlanetScale（Type E paradigm shift）對比：那條 path 是 no-Vitess → Vitess + branch、要學 Vitess 概念 + branch；本條是 已有 Vitess + 加 branch、只學 branch、複雜度低很多。

Driver：Ops headcount + Branch workflow + Vitess feature 加速

從自管 Vitess 遷 PlanetScale 的核心 driver：

Ops headcount 削減：

• 自管 Vitess 通常需要 2-5 個 SRE/DBA 撐 production —VTGate / VTTablet / VReplication / VSchema 各有議題
• PlanetScale 把這層全部 outsource、團隊 ops headcount 可降到 < 1 FTE
• 對 50-200 人 eng team、ops cost saving 是顯著 driver

Branch workflow paradigm：

• 自管 Vitess 仍用 gh-ost / pt-osc 或 Vitess online DDL 跑 schema migration、是 DBA 主導
• PlanetScale branch workflow 把 schema migration 變 developer self-service、開 branch / Deploy Request / merge、跟 git workflow 同節奏
• 對 high-velocity engineering culture 是文化升級

Vitess upstream feature：

• PlanetScale team 是 Vitess 的主要 contributor、新 feature 通常 PlanetScale 先 ship
• 自管 Vitess 升級慢、PlanetScale 用戶看到新 feature 早 3-6 個月

不適合 跨雲 portability priority high 或 strict on-prem deployment 的 org — PlanetScale 是 cloud-only。

Migration 階段：topology 盤點、雙 cluster 同步、讀切換、寫入切換與退役

Phase 1：Topology + VSchema audit

把當前自管 Vitess cluster 完整盤點：

 1# Vitess cluster topology
 2vtctldclient GetKeyspaces
 3vtctldclient GetShards <keyspace>
 4vtctldclient GetTablets
 5
 6# VSchema
 7vtctldclient GetVSchema <keyspace>
 8
 9# 跨 keyspace VReplication workflow
10vtctldclient GetWorkflows

對每個 keyspace 檢查：

• Shard 數量：PlanetScale plan 對 shard 數量有 limit（Enterprise 才能超大規模）
• VSchema features：自管可能用 PlanetScale 不支援的 Vindex（custom Vindex）
• Foreign key：Vitess 18+（2023 末）才支援 FK、自管 Vitess 大多 < 18、cluster 內已 application-enforced；遷 PlanetScale 後可選擇啟用 native FK（同 shard 內）或繼續 application enforcement
• Stored procedure / trigger：PlanetScale 受限、確認是否 application 依賴

完成標準：寫 blocker list（PlanetScale 不支援的功能）+ compatibility list（功能對應）。

Phase 2：Dual cluster + binlog stream

PlanetScale 內建 Vitess Connector、從外部 MySQL（包括其他 Vitess cluster）binlog stream import：

1# 1. 用 PlanetScale CLI 建 cluster
2pscale database create production --region us-east
3
4# 2. Import schema（從自管 Vitess export）
5pscale shell production main < schema.sql
6
7# 3. 設 Vitess Connector 從自管 cluster import 資料
8# （透過 PlanetScale Console）

Vitess Connector 從自管 VTTablet 的 MySQL primary 讀 binlog、寫進 PlanetScale。Lag 通常 < 1 秒。

跑 1-2 週、確認：

• Schema 完整 migrate
• VSchema 對應正確（Vindex 行為一致）
• Lag 穩定

Phase 3：Application read 切 PlanetScale

跟 Aurora migration 把讀流量切到 Aurora reader endpoint 的做法同概念。Application read query 切 PlanetScale endpoint：

• 連 PlanetScale connection string（xxx.connect.psdb.cloud）
• 仍寫自管 Vitess、Vitess Connector 同步 PlanetScale

跑 2-4 週、驗證：

• Query result 一致
• PlanetScale read latency 接近自管（PlanetScale Boost cache 可能加速）
• PlanetScale cluster 使用率與帳單跟預估一致

Phase 4：Write cutover + 自管 Vitess 退役

 1# 1. PlanetScale 把 cluster promote 為 primary（透過 Console）
 2# 透過 PlanetScale Console 啟用 production write 或用 `pscale` CLI 對應 promotion 命令
 3# （CLI 命令名稱隨 pscale 版本變動、以 pscale --help 為準）
 4
 5# 2. Application 寫 connection string 切 PlanetScale
 6# 自管 Vitess → PlanetScale
 7
 8# 3. Vitess Connector 反向（PlanetScale → 自管）作為 rollback buffer
 9
10# 4. 跑 1-2 週確認、開始 decommission 自管 Vitess

Decommission 自管 Vitess 是大工程：

• VTGate / VTTablet pods 一個個關
• VReplication workflow 停掉
• MySQL backend 保留作 cold backup 1-3 月、然後 EBS snapshot + terminate

完成標準：所有 traffic 在 PlanetScale、自管 Vitess 資源全 release、ops headcount confirm 下降。

Production 踩雷

VSchema 不完全兼容 — Custom Vindex 必須改

自管 Vitess 可能用了 custom Vindex（自寫 Go plugin）、PlanetScale 不支援 custom Vindex（只支援 built-in：hash / lookup_hash / unicode 等）。

修法：

• 在 topology + VSchema audit 階段找出所有 custom Vindex
• 對每個 custom Vindex 評估能否用 built-in 替代
• 不能替代的、考慮 application 層 logic 取代 Vindex（application 自己算 shard key）
• 或 暫不遷該 keyspace、保留自管 Vitess 跑 custom Vindex keyspace、其他遷 PlanetScale

Branch workflow 訓練不到位 — DBA 仍用「Vitess online DDL」心智模型

自管 Vitess team 習慣 vtctldclient ApplySchema --strategy=vitess 跑 online DDL、遷 PlanetScale 後仍想直接這樣 — 但 PlanetScale production branch 禁止 schema change、必須走 Deploy Request。

修法：

• write cutover 之前安排 branch workflow 訓練：team 每個 DBA / SRE 都跑過完整 branch + Deploy Request workflow
• 寫 team runbook：production schema change must 走 branch
• 緊急 schema change（事故中）也走 branch、PlanetScale 可加速 Deploy

SUPER privilege 移除 — 自管 admin tool 失效

自管 Vitess 用 SUPER privilege 跑 admin script、PlanetScale 沒給 SUPER。常見失效：

• 自寫 monitor script 跑 SHOW SLAVE STATUS、PlanetScale 抽象掉
• 自寫 backup script 跑 FLUSH TABLES WITH READ LOCK、PlanetScale 不允許
• 自寫 cleanup script 跑 KILL QUERY、PlanetScale 受限

修法：

• 在 topology + VSchema audit 階段一併盤點所有 admin script
• 改用 PlanetScale Console / CLI / API 等價操作
• PlanetScale 提供的 monitoring 介面替代自管監控

Connection limit — PlanetScale plan 比預期緊

PlanetScale Scaler Plan: 10K connection、Enterprise: 100K。自管 Vitess VTGate 通常設 50K-200K connection、遷 PlanetScale 後 hit limit。

修法：

• 在 topology + VSchema audit 階段做 connection forecast：peak hour 多少 active connection
• 升 PlanetScale plan（Scaler Pro / Enterprise）
• 或在 application 端加 connection pool（HikariCP / pgBouncer 等價）降低 connection count

Cost model 翻盤 — 帳單跟著 cluster 規格走、規格跟著 access pattern 走

截至 2026-09 的官方定價頁，PlanetScale 依所選 cluster 規格按月計費、單價依 region 而定；依 row read / written 計費的 Scaler 方案 2024-02-12 起停止新建，2024-04-12 起剩餘的 Scaler 資料庫全數轉為 Scaler Pro（現名 Base）。自管 Vitess 的成本是 EC2 + EBS，跟 infrastructure 規模線性相關。遷到 PlanetScale 之後，月帳由承載 workload 所需的 cluster 規格決定，而需要多大的規格由 application 的 access pattern 決定。

會把 cluster 規格往上推的 access pattern：

• Heavy analytics query（COUNT *、aggregation）掃大量 row，佔用 CPU 與 I/O
• N+1 query pattern 讓 application 發出大量小 SELECT，推高 QPS 與連線數
• Read-heavy workload 的讀取全部打在 primary

修法：

• 在 topology + VSchema audit 階段，用自管 Vitess 現有的 QPS、CPU 使用率與資料量對照官方定價頁的 cluster 規格，估算月帳
• 讀流量切到 PlanetScale 之後看實際的 cluster 使用率與帳單（application traffic 從這時才進 PlanetScale）
• Heavy analytics 改成 materialized view 或 async aggregation，不在每次 query 重算
• Read-heavy 的流量導到 replica，讓 primary 的規格只為寫入配置

Capability mapping

容量與成本對照

對 200 人 eng team 用自管 Vitess（10 shard、20 TB 資料、50K WPS）：

PlanetScale 端的總帳要把選定的 cluster 規格代入官方定價頁計算。ops headcount 從 2-3 FTE 降到 0.5 FTE 約省下 $225K-375K / yr，這是這條遷移路徑主要的成本理由：PlanetScale 的 cluster 月費與 storage 一年加總，要比自管的 infrastructure 與 storage 一年加總多不到這個數字才打平。對極大規模（> 200K WPS / > 100 TB）PlanetScale Enterprise 需要 commit pricing、不一定划算。

何時不要遷

• 跨雲 / on-prem 是 requirement：PlanetScale cloud-only
• Custom Vindex / 特殊 plugin 大量使用：兼容度低、改造工作量大
• 規模極大 > 500K WPS / > 200 TB：PlanetScale plan 對應 Enterprise commit、議價辛苦
• 強合規 / 資料主權限制：金融 / 政府 / 醫療場景、PlanetScale 不一定能 cover compliance
• 既有 Vitess team 強 + ops cost 低：如果 ops 已經精實、不必為 outsource 而 outsource

跟其他模組整合

跟 Vitess sharding

本 migration 保留 Vitess sharding 概念、application code 視角幾乎不變。Topology + VSchema audit 階段做的是 Vitess concept 對應 PlanetScale concept、不是 拆 Vitess 換 distributed SQL。

跟 → PlanetScale (from self-managed MySQL)

本 migration 的起點是自管 Vitess；自管 MySQL → PlanetScale 的起點是沒有 Vitess 的 MySQL。差異：

• MySQL → PlanetScale (Type E)：要學 Vitess 概念 + branch workflow + FK 處理
• Vitess → PlanetScale (Type C)：只學 branch workflow + ops outsource、保留所有 Vitess investment

選哪條 path 取決於起點。

跟 Major Version Upgrade

從自管 Vitess 上 MySQL 5.7 遷 PlanetScale 也是 同時跨 major version（PlanetScale 跑 8.0+ Vitess）。Application 必須同時處理 5.7 → 8.0 paradigm shift（charset / auth）。

相關連結

• MySQL vendor overview
• Vitess Sharding（self-managed source）
• → PlanetScale from self-managed MySQL（不同起點）
• → Aurora MySQL（另一條 self-managed → managed path）
• Major Version Upgrade（5.7 → 8.0 同期考量）
• 方法論：Migration Playbook Methodology（Type C operational hybrid）
• 官方：PlanetScale Migration Guide / Vitess Operator