雲端託管 PostgreSQL：AWS RDS、Aurora、Cloud SQL、Supabase、Neon 全面比較 | PostgreSQL

雲端託管 PostgreSQL 讓開發者不必操心硬體、備份與高可用性設定，專注於應用程式邏輯。從 AWS RDS、Aurora 到 Supabase、Neon，市場上的選擇琳瑯滿目。本文將從架構差異、HA 機制、Extension 支援到定價模型，全面比較各大平台的優劣。

為什麼選擇雲端託管？

自行管理 PostgreSQL 需要處理硬體採購、OS 修補、備份排程、HA 故障轉移、監控告警等大量維運工作。雲端託管服務（Managed PostgreSQL）將這些責任轉移給供應商，讓團隊專注於 Schema 設計、查詢最佳化與應用程式開發。

共同責任模型

Self-hosted PostgreSQL（自管）：
  使用者負責 → 硬體、OS、PostgreSQL 安裝、備份、HA、監控、安全性、升級

雲端 Managed PostgreSQL：
  供應商負責 → 硬體、OS 修補、PostgreSQL 安裝/升級、備份自動化、基礎設施 HA
  使用者負責 → Schema 設計、查詢最佳化、應用程式連線、資料安全政策、成本控管

責任轉移是 Managed 服務的核心價值，但同時也意味著對底層配置的控制度降低——某些進階調校（如修改 OS 核心參數、安裝任意 Extension）可能無法執行。

評估六大維度

選擇 Managed PostgreSQL 時，應從以下維度綜合考量：

AWS RDS for PostgreSQL

定位：AWS 生態系的傳統 Managed PostgreSQL，成熟穩定，整合度高。

核心特性

Extension 支援

RDS 採用白名單制度，支援 pg_stat_statements、pgvector、PostGIS、pg_partman、pg_cron、uuid-ossp 等大量預核准 Extension，但不允許安裝白名單外的 Extension。使用者沒有 superuser，僅有 rds_superuser 角色。

常用操作

# 查看 RDS 實例
aws rds describe-db-instances --db-instance-identifier mydb

# 建立快照
aws rds create-db-snapshot \
  --db-instance-identifier mydb \
  --db-snapshot-identifier mydb-snapshot-20260724

# 觸發 Multi-AZ Failover 測試
aws rds reboot-db-instance \
  --db-instance-identifier mydb \
  --force-failover

-- 查詢可用 Extension 白名單
SELECT name FROM pg_available_extensions ORDER BY name;

-- 啟用 Extension
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS pgvector;

限制

• 無法修改 shared_preload_libraries 中的所有參數（需透過 Parameter Group，重啟才生效）
• 不支援自訂 OS 層配置
• 部分 Extension 安裝需等待 RDS 官方支援

AWS Aurora PostgreSQL

定位：AWS 自研雲端原生資料庫，PostgreSQL 相容，運算與儲存分離架構，效能顯著優於標準 RDS。

架構差異

標準 RDS PostgreSQL 架構：
  Primary Instance ──WAL 複製──→ Standby（Multi-AZ）
  Primary Instance ──非同步──→ Read Replica

Aurora PostgreSQL 架構：
  Primary Instance ─┐
  Read Replica 1  ─┤── 共用 Aurora Storage（6 副本，跨 3 個 AZ）
  Read Replica 2  ─┘
       ↕
  Aurora Storage Layer（分散式日誌，自動 6 副本複製）

Aurora 的關鍵創新在於共享儲存層——所有運算節點共用同一份資料，Read Replica 不需要複製 WAL，延遲穩定在 100ms 以內。

Aurora vs RDS 比較

Aurora Serverless v2

計算能力以 ACU（Aurora Capacity Unit）為單位，在 0.5 到設定上限之間自動伸縮，按實際使用的 ACU 秒數計費。適合工作負載不均勻的場景。

注意：Aurora Serverless v2 最低收費 0.5 ACU，並非真正的「零縮容」。與 Neon 等可完全停止計算的設計有本質差異。

# 建立 Aurora Read Replica
aws rds create-db-instance \
  --db-instance-identifier mydb-reader-1 \
  --db-instance-class db.r6g.large \
  --engine aurora-postgresql \
  --db-cluster-identifier mydb-cluster

GCP Cloud SQL for PostgreSQL

定位：GCP 生態系的標準 Managed PostgreSQL，基於 Compute Engine VM + Persistent Disk。

核心特性

與 RDS 的關鍵差異

• PITR 保留期較短（7 天 vs RDS 最多 35 天）
• Cloud SQL Auth Proxy 的 IAM 整合比 RDS Proxy 更安全便利
• Read Replica 支援 Cascaded 架構，可減輕 Primary 的複製負擔

# 使用 Cloud SQL Auth Proxy 連線（推薦方式）
cloud_sql_proxy -instances=PROJECT:REGION:INSTANCE=tcp:5432 &
psql -h 127.0.0.1 -U postgres -d mydb

# 建立 Read Replica
gcloud sql instances create mydb-replica \
  --master-instance-name=mydb \
  --region=asia-east1

GCP AlloyDB for PostgreSQL

定位：GCP 自研 PostgreSQL 相容資料庫，對標 Aurora，內建 Columnar Engine 加速分析查詢。

架構核心

AlloyDB 架構：
  Primary Instance ─┐
  Read Pool 節點1  ─┤── AlloyDB Storage Layer（分散式 WAL 儲存）
  Read Pool 節點2  ─┘       ↕
                      Columnar Engine（記憶體，自動選擇列式/行式掃描）

核心優勢

• Columnar Engine：分析型查詢（COUNT/SUM/大範圍掃描）快 100 倍，無需 ETL 到 BigQuery
• Read Pool：共享儲存層，新增節點無需資料複製，秒級上線
• AlloyDB AI：原生整合 pgvector + ScaNN 向量索引，直接呼叫 Vertex AI Embeddings
• SLA 99.99%：Failover 通常 30 秒內完成

AlloyDB 最適合需要 HTAP（混合事務/分析處理）的場景——在同一資料庫內同時執行 OLTP 和輕量 OLAP。

Azure Database for PostgreSQL — Flexible Server

定位：Microsoft Azure 的主力 Managed PostgreSQL 服務。

核心特性

重要特色

Azure Flexible Server 的三大差異化特色：

1. 內建 PgBouncer：原生提供連線池，在連線字串中加入 pgbouncer=on 即可啟用
2. Microsoft Entra 整合：支援 Azure AD 帳戶（含 Managed Identity）直接驗證連線，實現零秘鑰架構
3. Intelligent Tuning：自動偵測查詢效能回退並建議索引

Supabase

定位：以 PostgreSQL 為核心的開源 BaaS（Backend-as-a-Service），Firebase 的開源替代方案。

不只是資料庫

每個 Supabase Project 是一個獨立的 PostgreSQL 實例，使用者擁有完整的 postgres superuser 存取權限。除了資料庫，還提供：

Row Level Security（RLS）

Supabase 將 RLS 作為資料安全的核心機制，讓應用程式可直接從客戶端連接資料庫，無需後端 API 層作為安全邊界：

-- 啟用 RLS
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

-- 使用者只能讀取自己的文章
CREATE POLICY "Users can view own posts"
  ON posts FOR SELECT
  USING (auth.uid() = user_id);

-- 使用者只能建立屬於自己的文章
CREATE POLICY "Users can insert own posts"
  ON posts FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- 使用者只能更新自己的文章
CREATE POLICY "Users can update own posts"
  ON posts FOR UPDATE
  USING (auth.uid() = user_id);

-- 查詢當前使用者資訊
SELECT auth.uid();    -- 當前使用者 UUID
SELECT auth.role();   -- authenticated / anon / service_role

Extension 支援

由於使用者擁有 superuser，Extension 支援度最高，幾乎可安裝任何 Extension。預裝包括 pgvector、PostGIS、pg_cron、pg_net、pg_graphql、pgjwt 等。

定價

• Free Tier：500MB 儲存，50,000 MAU Auth，500MB 頻寬
• Pro：$25/月起，8GB RAM
• 注意：Free Tier 實例 7 天不活躍後會自動暫停

Neon — Serverless PostgreSQL

定位：真正的 Serverless PostgreSQL，運算與儲存完全分離，支援資料庫分支（Branching），閒置時計算層自動縮容至零。

架構創新

Neon 架構：
  Compute Layer：
    - 標準 PostgreSQL 進程（冷啟動約 500ms）
    - 閒置後自動暫停（Autosuspend），計費停止
    - 多個 Compute 可讀同一份 Storage

  Storage Layer：
    - Pageserver：分散式頁面服務（類似 Aurora）
    - Safekeeper：WAL 高可用儲存（Raft 共識，3 副本）
    - Copy-on-Write 快照：O(1) 時間建立 Branch

Branching（殺手級功能）

Neon 最獨特的功能——類似 git 分支概念，每個 Branch 是資料庫的即時複本：

# 安裝 Neon CLI
npm install -g neonctl

# 建立生產資料庫的開發 Branch
neonctl branches create --name dev/feature-payment --parent main

# 取得 Branch 連線字串
neonctl connection-string dev/feature-payment

# 測試完成後刪除
neonctl branches delete dev/feature-payment

Branch 的核心使用場景：

• 開發/測試環境：每個 PR 建立獨立 Branch，測試完畢刪除
• Schema Migration 預演：在 Branch 執行 Migration 腳本，驗證無誤後再套用至 Production
• Preview Environment：CI/CD 中自動建立 Branch 對應 Vercel Preview Deployment

# GitHub Actions 範例
- name: Create Neon Branch
  run: |
    BRANCH_NAME="ci/pr-${{ github.event.number }}"
    neonctl branches create --name $BRANCH_NAME --parent main
    DB_URL=$(neonctl connection-string $BRANCH_NAME)
    echo "DATABASE_URL=$DB_URL" >> $GITHUB_ENV

Serverless Driver

針對 Edge 環境設計的輕量驅動程式：

// Neon Serverless Driver（HTTP over WebSocket）
import { neon } from '@neondatabase/serverless';
const sql = neon(process.env.DATABASE_URL);
const result = await sql`SELECT 1`;

// 相比傳統 node-postgres，每次函數呼叫無需建立 TCP 連線

冷啟動注意事項

閒置後重新啟動需約 500ms。對延遲敏感的場景可：

• 設定較長 suspend_timeout（如 60 分鐘）
• 使用 Connection Pooler 保持最小連線數
• 定期心跳查詢防止 Compute 暫停

定價

• Free Tier：0.5GB 儲存，1 個 Project，無限 Branch
• Launch：$19/月，10GB 儲存，自動伸縮至 10 CU
• 計費單位：CU（1 vCPU + 4GB RAM），按秒計費

Tembo — Extension 為中心的平台

定位：以 PostgreSQL Extension 為中心的 Managed 服務，提供「Stack（堆疊）」概念——針對不同工作負載預先配置最佳化的 Extension 組合。

Stack 類型

Tembo 的理念是「Postgres for Everything」——透過適當的 Extension 組合，讓 PostgreSQL 取代多種專用資料庫。

綜合比較矩陣

高可用性架構比較

不同平台的 HA 機制差異顯著，直接影響 Failover 時間與資料安全：

共享儲存（Failover 最快，無需資料複製）：
  Aurora PostgreSQL    → <30s（Fast Failover）
  AlloyDB             → <60s（共享 Storage Layer）
  Neon                → 內建（Safekeeper Raft 共識）

同步複製（零資料遺失，Failover 較慢）：
  Cloud SQL HA        → 約 30-60s（Persistent Disk 同步複製）
  Azure Zone-Redundant → 約 60-120s
  RDS Multi-AZ        → 約 60-120s

非 HA（單節點）：
  Supabase Free Tier  → 無 HA，依賴備份還原
  Neon Compute        → 單 Compute，但 Storage 層高可用

備份策略差異

Connection Pooling 策略

Managed 服務通常有連線數上限限制，各平台的連線池策略：

AWS RDS / Aurora：
  → RDS Proxy（託管 PgBouncer，支援 IAM 認證，額外費用）
  → 或在應用層使用 PgBouncer

Cloud SQL：
  → Cloud SQL Auth Proxy + 應用層連線池

Azure Flexible Server：
  → 內建 PgBouncer（免費，連線字串加入 pgbouncer=on）

Supabase：
  → 內建 PgBouncer（Transaction Mode 6543 埠，Session Mode 5432 埠）
  → 推薦：Serverless Functions 使用 Transaction Mode

Neon：
  → 內建連線池 + Serverless Driver（HTTP over WebSocket）

Extension 支援深度

Superuser 完整控制：
  Supabase > Tembo > Self-hosted

白名單 Extension（主流 Extension 均可用）：
  RDS ≈ Aurora ≈ Cloud SQL ≈ AlloyDB ≈ Azure Flexible ≈ Neon

pgvector：全部平台均支援
PostGIS：全部平台均支援
pg_cron：除 Neon 外均支援
timescaledb：Tembo 原生，Azure 需啟用，其他有限支援

自訂 Extension（非白名單）：
  僅 Supabase（superuser）與 Tembo（Trunk）支援

成本結構比較

固定計費模式（傳統三大雲）

按實例規格（vCPU + RAM）+ 儲存 + I/O + 網路流量分項計費。HA 模式通常費用約 2 倍。適合工作負載穩定且持續的應用。

Serverless 計費模式（Neon、Aurora Serverless v2）

按實際使用的計算時間計費。閒置時費用大幅降低（Neon 可降至 $0，Aurora v2 最低 0.5 ACU）。適合工作負載不均勻、開發/測試環境。

BaaS 計費模式（Supabase）

包含 Auth、Storage、Edge Functions 等額外服務的整合定價。Free Tier 可能已足夠小型應用。適合需要完整後端能力的全端專案。

供應商鎖定風險管理

PostgreSQL 的可攜性是其最大優勢，但 Managed 服務可能引入鎖定風險：

高鎖定風險因素

• 使用僅特定平台支援的 Extension（AlloyDB ScaNN、Supabase pg_graphql）
• 依賴平台特有連線機制（Cloud SQL Auth Proxy IAM 整合）
• 使用 Aurora Serverless v2 的自動伸縮語意
• 依賴 Neon 的 Branching（其他平台無等效功能）

降低鎖定策略

• 優先使用跨平台支援的 Extension（pgvector、PostGIS、pg_stat_statements）
• 抽象化連線字串管理，使用標準 libpq URI 格式
• 定期執行 pg_dump 備份並驗證可在其他平台還原
• 避免在應用程式碼中硬寫平台特有的 SQL 方言

Self-hosted vs Managed 決策框架

決策流程

需要自訂 Extension 或 OS 級別配置？
  → 是 → Self-hosted（或 Supabase / Tembo）
  → 否 ↓

已深度整合某雲端供應商生態？
  → AWS   → RDS 或 Aurora（高效能）
  → GCP   → Cloud SQL 或 AlloyDB（高效能/分析）
  → Azure → Flexible Server
  → 無偏好 ↓

工作負載是否高度不均勻或有大量閒置時間？
  → 是 → Neon（Serverless）或 Aurora Serverless v2
  → 否 ↓

是否需要整合 Auth/Storage/API 等完整後端？
  → 是 → Supabase（BaaS）
  → 否 → 根據預算選擇標準 Managed 服務

Serverless PostgreSQL 的使用限制

Serverless 形態在某些場景下有固有限制：

冷啟動問題

解決方案

防止冷啟動的三種策略：

1. 延長暫停時間
   → 設定 suspend_timeout = 3600（1小時）
   → 接受較高待機費用

2. 保持最小連線
   → Connection Pooler 定期心跳
   → 防止 Compute 進入暫停

3. Warm-up 策略
   → 定期排程查詢（如每 5 分鐘 SELECT 1）
   → 適合延遲敏感的端點

遷移路徑

Self-hosted → Managed

# 方法一：pg_dump/pg_restore（離線遷移）
pg_dump -Fc -h source -U user dbname > backup.dump
pg_restore -h managed-host -U user -d dbname backup.dump

# 方法二：邏輯複製（零停機遷移）
# 在源端建立 Publication
CREATE PUBLICATION my_pub FOR ALL TABLES;

# 在目標端建立 Subscription
CREATE SUBSCRIPTION my_sub
  CONNECTION 'host=source dbname=mydb user=repl_user'
  PUBLICATION my_pub;

跨平台遷移注意事項

• 檢查 Extension 相容性（源平台支援但目標平台白名單不含的 Extension）
• 確認 Role 與 Permission 映射（rds_superuser vs cloudsqlsuperuser vs postgres）
• 測試應用程式連線字串與驅動程式相容性

選型建議總結

總結

雲端託管 PostgreSQL 的市場已從三大雲供應商的傳統 Managed 服務，擴展到 Serverless 原生（Neon）、BaaS 整合（Supabase）與 Extension 專精（Tembo）的多元生態。選擇時沒有「最佳」方案，只有「最適合你的場景」的方案——關鍵在於釐清你的 HA 需求、Extension 依賴、預算模型與團隊能力。

核心原則：所有平台底層都是 PostgreSQL，你的 SQL 知識與 Schema 設計能力是跨平台通用的。善用 pg_dump 保持可攜性，避免過度依賴平台特有功能，就能在需要時順利遷移。

下一篇，我們將探討 PostgreSQL 開發者工具——從 pgAdmin、DBeaver 到 DataGrip，掌握提升 PostgreSQL 開發效率的必備工具與工作流程。