Specialized PostgreSQL Variants
Specialized PostgreSQL variants 的核心責任是把 PostgreSQL ecosystem 裡的 specialized engines、extensions 與 managed variants 放到正確服務位置。PostgreSQL 的擴充性讓它能支援 geospatial、time-series、vector search、distributed table、serverless branch 與 managed acceleration；但每個變體都改變 operation、migration、cost 與 lock-in。
本文的判讀錨點是：PostgreSQL compatibility 是入口，不等於相同責任。選 variant 前，要先說清楚新增能力解決哪個 workload，並確認 exit route。
Variant Taxonomy
Variant taxonomy 的核心責任是把變體按資料模型與操作責任分類。
| 類型 | 代表 | 主要解決問題 |
|---|---|---|
| Extension domain | PostGIS、pgvector、TimescaleDB | geospatial、vector、time-series |
| Distributed PG | Citus、Cosmos DB for PostgreSQL | sharding、distributed query |
| Managed accelerated PG | AlloyDB、Aurora PG | managed performance / HA / platform |
| Serverless / branching | Neon、Supabase workflow | preview、branch、稀疏 workload |
| Compatibility layer | YugabyteDB、部分 distributed SQL | PostgreSQL-like API + distributed storage |
分類的重點是避免把不同變體視為同一種升級。Extension domain 強化單一資料模型；distributed PG 改變資料拓撲；managed accelerated PG 改變操作邊界；serverless PG 改變 lifecycle。
Workload Fit
Workload fit 的核心責任是判斷 variant 是否匹配資料形狀。
| Workload | 合適路線 | 審查問題 |
|---|---|---|
| Geospatial query | PostGIS | index、SRID、資料量、query latency |
| Time-series retention | TimescaleDB / partition strategy | compression、chunk、retention |
| Vector search | pgvector / pgvectorscale | recall、latency、index build、hybrid search |
| Tenant sharding | Citus / distributed PG | distribution key、co-location、rebalance |
| Preview environment | serverless / branching PG | data privacy、branch lifecycle |
| Cloud-managed acceleration | AlloyDB / Aurora | compatibility、cost、exit |
Variant 要先證明普通 PostgreSQL 加 index / partition / read replica 已到邊界。若基礎 query design 還沒成熟，導入 variant 會把複雜度提前。
Migration Gap
Migration gap 的核心責任是列出從 vanilla PostgreSQL 進入 variant 的差異。
| 差異面 | 審查問題 |
|---|---|
| DDL | extension object、distributed table、chunk |
| Query | planner、function、operator、pushdown |
| Data movement | backfill、reshard、index build |
| Operation | backup、restore、upgrade、failover |
| Tooling | ORM、migration tool、CDC、monitoring |
| Exit | dump / restore 是否回到 vanilla PG |
Migration 要有 compatibility test。每個核心 query 在 variant 上跑 explain、latency、result correctness；每個 migration step 都要有 rollback 或 rebuild path。
Lock-In and Exit
Lock-in and exit 的核心責任是把 variant-specific 能力和可攜性分開。
| Lock-in 來源 | 控制方式 |
|---|---|
| Extension-specific type | adapter layer、domain boundary |
| Managed-only feature | decision record、exit test |
| Distributed table DDL | topology doc、reshard runbook |
| Serverless branch API | dev workflow boundary |
| Proprietary index / function | fallback query / export strategy |
Lock-in 可以接受，但要被命名。若 variant 能顯著降低成本或提高能力，採用是合理決策；工程責任是保留 exit evidence 與 migration plan。
Decision Matrix
Decision matrix 的核心責任是把 variant 路由接到 PostgreSQL 主章。
| 訊號 | 下一步 |
|---|---|
| 地理查詢是核心產品能力 | PostGIS Deep Dive |
| 時序資料與 retention 是主壓力 | TimescaleDB Deep Dive |
| 向量搜尋在 PG 內整合 | pgvector Deep Dive |
| tenant sharding / distributed query | Citus Distributed |
| managed provider 選型 | Managed PostgreSQL Comparison |
| 分散式 SQL API 相容評估 | PostgreSQL to YugabyteDB / TiDB |
Decision matrix 要隨案例更新。Variant 選型最需要實際 workload：資料量、query pattern、SLO、team skill、合規與 exit 成本。
Review Checklist
Review checklist 的核心責任是避免 specialized variant 只被功能吸引。
- Workload 是否真的需要 specialized capability。
- Vanilla PostgreSQL 的 index / partition / replica 是否已評估。
- Extension / managed feature 的版本與支援政策。
- Backup / restore / upgrade runbook。
- Migration tool、CDC、observability 是否支援。
- Exit route 是否至少在 staging 演練。
- 成本模型是否包含 storage、compute、I/O、support、operation。
完成 checklist 後，variant 才能進入正式 proposal。這樣可以保留 PostgreSQL ecosystem 的彈性，也避免變體變成隱形平台遷移。
下一步路由
Specialized variants 完成後，回到 PostgreSQL overview 做服務定位；需要 managed provider 比較讀 Managed PostgreSQL Comparison；需要跨 vendor migration 讀 Database Migration Playbook。