Managed-Service on Tarragonhttps://tarrragon.github.io/blog/tags/managed-service/Recent content in Managed-Service on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 22 May 2026 00:00:00 +0000Managed PostgreSQL Comparisonhttps://tarrragon.github.io/blog/backend/01-database/vendors/postgresql/managed-pg-comparison/Fri, 22 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/01-database/vendors/postgresql/managed-pg-comparison/<p>Managed PostgreSQL comparison 的核心責任是把「都是 PostgreSQL」拆成不同的操作責任邊界。Managed service 可能代管 backup、patch、replica、minor upgrade、monitoring、connection proxy、serverless scaling 或 branch workflow；但 application schema、query、migration、role、cost 與 incident decision 仍需要 team 承擔。</p> <p>本文的判讀錨點是：managed PostgreSQL 是 operation trade-off，而非 vendor-neutral checkbox。選型要看 workload、合規、extension、HA / DR、connection、cost visibility、exit route 與 team skill。</p> <p>官方文件路由的核心責任是固定 provider claim。實作前分別查 <a href="https://docs.cloud.google.com/alloydb/docs">AlloyDB docs</a>、<a href="https://cloud.google.com/sql/postgresql">Cloud SQL for PostgreSQL</a>、<a href="https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/overview">Azure Database for PostgreSQL Flexible Server</a> 與 <a href="https://supabase.com/docs/guides/deployment/branching">Supabase branching docs</a>；本文最後檢查日是 2026-05-22。</p> <h2 id="provider-boundary">Provider Boundary</h2> <p>Provider boundary 的核心責任是定義 vendor 接手哪些資料庫操作。</p> <table> <thead> <tr> <th>類型</th> <th>代表選項</th> <th>適合情境</th> </tr> </thead> <tbody> <tr> <td>Cloud managed PostgreSQL</td> <td>RDS PostgreSQL、Cloud SQL、Azure PG</td> <td>標準 PostgreSQL、雲平台整合</td> </tr> <tr> <td>Aurora PostgreSQL-compatible</td> <td>Amazon Aurora PostgreSQL</td> <td>AWS 生態、高可用 storage layer、read scaling</td> </tr> <tr> <td>Serverless / branching PG</td> <td>Neon、Supabase 部分能力</td> <td>dev preview、稀疏 workload、快速分支</td> </tr> <tr> <td>Specialist managed PG</td> <td>Crunchy Bridge 等</td> <td>PostgreSQL 專業支援、extension 需求</td> </tr> <tr> <td>Self-managed</td> <td>VM / K8s 上自管</td> <td>需要完整控制、具備 DBA 能力</td> </tr> </tbody> </table> <p>Provider boundary 要寫成 responsibility matrix。誰負責 backup restore、major upgrade、extension enable、failover、connection proxy、audit export、encryption key、support ticket 與 incident decision。</p> <p>Serverless / branching PG 這一列的 Neon 與 Supabase 不在同一個 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/capability-outsourcing-depth/" data-link-title="Capability Outsourcing Depth（外包深度）" data-link-desc="說明外包一塊後端能力有三種深度（managed 基礎設施、feature SaaS、BaaS bundle）、深度決定保留多少控制權與遷出代價">外包深度</a>。Neon 是純 serverless PostgreSQL（managed 基礎設施）；Supabase 是把 Postgres 當其中一塊的 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/baas/" data-link-title="BaaS（Backend as a Service）" data-link-desc="說明把認證、資料庫、檔案儲存、推播打包成現成模組、由前端 SDK 直連的後端交付形態">BaaS bundle</a>（同時含 Auth、Storage、Realtime）。只需要資料庫、兩者皆可比較且 Neon 更輕；要連認證、儲存一起到位、才是 Supabase 的賣點。這個外包深度差異與「該買整個 bundle 還是只用它的 Postgres」的判讀、見 <a href="https://tarrragon.github.io/blog/backend/00-service-selection/capability-buy-vs-build/" data-link-title="0.22 能力級買 vs 建：feature-as-a-service 與 BaaS bundle 選型" data-link-desc="在交付形態決定整個系統要不要自建之後、逐能力判斷該外包還是自建：辨識 managed 基礎設施、feature SaaS 與 BaaS bundle 三種外包深度、no-code 到 dev-tool 的服務光譜、買 vs 建判準與權重浮動、整合接縫與遷出代價">0.22 能力級買 vs 建</a>。</p> <h2 id="evaluation-dimensions">Evaluation Dimensions</h2> <p>Evaluation dimensions 的核心責任是讓比較避免只看價格或品牌。</p> <table> <thead> <tr> <th>維度</th> <th>審查問題</th> </tr> </thead> <tbody> <tr> <td>PostgreSQL fidelity</td> <td>engine version、extension、parameter、superuser 限制</td> </tr> <tr> <td>HA / DR</td> <td>AZ failover、cross-region replica、PITR、restore drill</td> </tr> <tr> <td>Connection</td> <td>max connection、pooler、proxy、serverless cold start</td> </tr> <tr> <td>Migration</td> <td>import/export、logical replication、downtime window</td> </tr> <tr> <td>Observability</td> <td>logs、metrics、slow query、audit、SIEM export</td> </tr> <tr> <td>Security</td> <td>network、IAM、KMS、TLS、RLS / pgAudit support</td> </tr> <tr> <td>Cost</td> <td>instance、storage、I/O、backup、egress、support</td> </tr> <tr> <td>Exit</td> <td>dump、logical replication、snapshot portability</td> </tr> </tbody> </table> <p>PostgreSQL fidelity 是第一關。若服務依賴 extension、logical decoding、superuser function、custom parameter 或 filesystem access，managed provider 的限制會直接影響可行性。</p>Managed PostgreSQL comparison 的核心責任是把「都是 PostgreSQL」拆成不同的操作責任邊界。Managed service 可能代管 backup、patch、replica、minor upgrade、monitoring、connection proxy、serverless scaling 或 branch workflow；但 application schema、query、migration、role、cost 與 incident decision 仍需要 team 承擔。

本文的判讀錨點是：managed PostgreSQL 是 operation trade-off，而非 vendor-neutral checkbox。選型要看 workload、合規、extension、HA / DR、connection、cost visibility、exit route 與 team skill。

官方文件路由的核心責任是固定 provider claim。實作前分別查 AlloyDB docs、Cloud SQL for PostgreSQL、Azure Database for PostgreSQL Flexible Server 與 Supabase branching docs；本文最後檢查日是 2026-05-22。

Provider Boundary

Provider boundary 的核心責任是定義 vendor 接手哪些資料庫操作。

類型 代表選項 適合情境
Cloud managed PostgreSQL RDS PostgreSQL、Cloud SQL、Azure PG 標準 PostgreSQL、雲平台整合
Aurora PostgreSQL-compatible Amazon Aurora PostgreSQL AWS 生態、高可用 storage layer、read scaling
Serverless / branching PG Neon、Supabase 部分能力 dev preview、稀疏 workload、快速分支
Specialist managed PG Crunchy Bridge 等 PostgreSQL 專業支援、extension 需求
Self-managed VM / K8s 上自管 需要完整控制、具備 DBA 能力

Provider boundary 要寫成 responsibility matrix。誰負責 backup restore、major upgrade、extension enable、failover、connection proxy、audit export、encryption key、support ticket 與 incident decision。

Serverless / branching PG 這一列的 Neon 與 Supabase 不在同一個 外包深度。Neon 是純 serverless PostgreSQL（managed 基礎設施）；Supabase 是把 Postgres 當其中一塊的 BaaS bundle（同時含 Auth、Storage、Realtime）。只需要資料庫、兩者皆可比較且 Neon 更輕；要連認證、儲存一起到位、才是 Supabase 的賣點。這個外包深度差異與「該買整個 bundle 還是只用它的 Postgres」的判讀、見 0.22 能力級買 vs 建。

Evaluation Dimensions

Evaluation dimensions 的核心責任是讓比較避免只看價格或品牌。

維度 審查問題
PostgreSQL fidelity engine version、extension、parameter、superuser 限制
HA / DR AZ failover、cross-region replica、PITR、restore drill
Connection max connection、pooler、proxy、serverless cold start
Migration import/export、logical replication、downtime window
Observability logs、metrics、slow query、audit、SIEM export
Security network、IAM、KMS、TLS、RLS / pgAudit support
Cost instance、storage、I/O、backup、egress、support
Exit dump、logical replication、snapshot portability

PostgreSQL fidelity 是第一關。若服務依賴 extension、logical decoding、superuser function、custom parameter 或 filesystem access，managed provider 的限制會直接影響可行性。

Workload Fit

Workload fit 的核心責任是把 provider 能力和產品需求對齊。

Workload 優先考量
SaaS OLTP HA、PITR、connection pool、online migration
Analytics-heavy OLTP read replica、I/O cost、work_mem、warehouse boundary
Dev / preview env branching、fast restore、low idle cost
Regulated workload audit、KMS、network isolation、retention
Extension-heavy app PostGIS、pgvector、TimescaleDB、logical decoding support

Serverless / branching PG 適合 preview 與稀疏 workload，但 sustained high-throughput production 要審查 cold start、connection、storage separation latency 與 cost curve。

Aurora PostgreSQL 適合 AWS-heavy 架構與高可用 storage layer，但要審查 PostgreSQL compatibility、parameter 限制、I/O cost 與 migration / exit。

Migration and Exit

Migration and exit 的核心責任是避免 managed service 變成單向門。導入前要先知道如何進去、如何出來。

流程 Evidence
Import dump / restore、logical replication、DMS
Cutover freeze window、replica catch-up、validation
Rollback source snapshot、write replay、DNS switch
Exit pg_dump、logical replication、snapshot export
Rehearsal staging restore、row count、checksum

Exit route 要比口頭承諾更具體。至少要能在 staging 將資料匯出到 vanilla PostgreSQL 或下一個 managed provider，並跑 application smoke test。

Cost Review

Cost review 的核心責任是把 managed convenience 轉成總成本。總成本包含 instance、storage、I/O、backup、replica、egress、support、observability、operation labor 與 incident cost。

Cost driver 常見誤判
I/O 只看 instance price
Backup retention 長 retention 被忽略
Cross-region replica data transfer / storage 增加
Observability export log volume 與 SIEM 成本
Serverless idle idle 低但 sustained workload 成本不同

Cost review 要設 tripwire。當 I/O 成本占比提高、backup retention 變長、replica 增加或 serverless workload 變成常駐，重新評估方案。

Decision Route

Decision route 的核心責任是把 provider 選型導向具體路線。

需求 優先路由
標準雲平台 PostgreSQL RDS / Cloud SQL / Azure PG
AWS 生態 + HA storage layer Aurora PostgreSQL
Preview branch / dev env Neon / Supabase branch workflow
Extension / PG 專業支援 specialist managed PG
完整控制與特殊 extension self-managed PostgreSQL

Managed provider 的最終選擇要回到 team skill。少維護元件是價值；把尚未理解的限制外包給 vendor，會在 incident 和 migration 時回來。

下一步路由

Managed PostgreSQL comparison 完成後，Aurora 遷移讀 PostgreSQL to Aurora Migration；Aurora DSQL 讀 PostgreSQL to Aurora DSQL；serverless / specialized variant 讀 Specialized PostgreSQL Variants。

]]>