Cloud Native Database 選型指南：PostgreSQL、NoSQL 與雲原生資料庫比較【2025】

「資料庫可以跑在 Kubernetes 上嗎？」這個問題五年前的答案是「最好不要」。但現在，越來越多企業把資料庫放到 K8s 上，而且跑得很好。

這篇文章會介紹 Cloud Native Database 的概念，重點介紹 CloudNativePG（雲原生 PostgreSQL），並比較各種雲原生資料庫方案，幫你做出適合的選型決策。

---

什麼是 Cloud Native Database？

雲原生資料庫定義

Cloud Native Database 是專為雲端和容器環境設計的資料庫，具備以下特性：

• 容器化：可以打包成容器映像
• 可編排：可以用 Kubernetes 管理
• 彈性擴展：可以根據負載自動擴縮
• 自我修復：節點故障時自動恢復
• 宣告式配置：用 YAML 定義期望狀態

這不是說傳統資料庫（MySQL、PostgreSQL）不能用在 Cloud Native 環境。而是需要搭配 Operator 等工具，讓它們具備雲原生特性。

傳統資料庫 vs Cloud Native 資料庫

面向	傳統部署	Cloud Native
部署方式	安裝在 VM 或實體機	容器 + Operator
高可用	手動設定 Replication	Operator 自動管理
備份	定時腳本	宣告式備份政策
擴展	手動增加節點	改 YAML 自動擴展
故障恢復	手動介入	自動 Failover
監控	獨立監控系統	Prometheus 整合

為什麼需要 Cloud Native Database？

1. 統一管理

應用程式和資料庫都在 Kubernetes 上，用同一套工具管理。不需要分開維護 VM 和容器兩套環境。

2. 環境一致性

開發、測試、生產環境可以用相同的資料庫配置。符合 12 Factor 的 Dev/Prod Parity 原則。

3. GitOps 支援

資料庫的配置可以存在 Git 裡，透過 PR 流程管理變更。

4. 快速環境搭建

新專案或新環境，幾分鐘就能建好完整的資料庫。

想了解 Cloud Native 完整概念？請參考 Cloud Native 完整指南。

---

Cloud Native PostgreSQL（CloudNativePG）

CloudNativePG 介紹

CloudNativePG 是 CNCF Sandbox 專案，專為 Kubernetes 設計的 PostgreSQL Operator。它讓你可以用 Kubernetes 原生的方式管理 PostgreSQL 叢集。

專案背景：

• 由 EDB（EnterpriseDB）開發
• 2022 年捐贈給 CNCF
• 目前是最活躍的 PostgreSQL Operator

和其他 Operator 的差異：

Operator	優點	缺點
CloudNativePG	功能完整、CNCF 支持	較新
Zalando Postgres Operator	穩定、大規模驗證	設定較複雜
CrunchyData PGO	企業級功能	商業背景

核心功能

1. 高可用叢集

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres
spec:
  instances: 3  # 1 Primary + 2 Standby
  primaryUpdateStrategy: unsupervised
  postgresql:
    parameters:
      max_connections: "200"
      shared_buffers: "256MB"
  storage:
    size: 10Gi
    storageClass: fast-storage

Operator 會自動：

• 建立 1 個 Primary 和 2 個 Standby
• 設定 Streaming Replication
• Primary 故障時自動 Failover

2. 自動備份

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres
spec:
  instances: 3
  backup:
    barmanObjectStore:
      destinationPath: s3://my-bucket/backups
      s3Credentials:
        accessKeyId:
          name: s3-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: s3-creds
          key: SECRET_ACCESS_KEY
    retentionPolicy: "30d"
  # 排程備份
  scheduledBackups:
  - name: daily-backup
    schedule: "0 2 * * *"  # 每天凌晨 2 點
    backupOwnerReference: self

3. 宣告式配置

PostgreSQL 的參數可以透過 YAML 設定，變更會自動套用：

spec:
  postgresql:
    parameters:
      max_connections: "300"
      work_mem: "64MB"
      maintenance_work_mem: "256MB"
      effective_cache_size: "1GB"

4. 監控整合

內建 Prometheus metrics 端點，可以直接接入現有的監控系統：

spec:
  monitoring:
    enablePodMonitor: true  # 自動建立 PodMonitor

架構設計

CloudNativePG 的架構：

┌─────────────────────────────────────────────────────┐
│  CloudNativePG Operator                              │
│  └─ 監控 Cluster CR，維護期望狀態                    │
└─────────────────────┬───────────────────────────────┘
                      │
┌─────────────────────▼───────────────────────────────┐
│  PostgreSQL Cluster                                  │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐   │
│  │  Primary    │ │  Standby 1  │ │  Standby 2  │   │
│  │  (RW)       │ │  (RO)       │ │  (RO)       │   │
│  └──────┬──────┘ └──────┬──────┘ └──────┬──────┘   │
│         │               │               │           │
│         └───────────────┴───────────────┘           │
│              Streaming Replication                  │
├─────────────────────────────────────────────────────┤
│  Services                                           │
│  ├─ my-postgres-rw  (指向 Primary)                 │
│  └─ my-postgres-ro  (指向 Standby)                 │
└─────────────────────────────────────────────────────┘

適用場景

適合 CloudNativePG 的情況：

• 已經使用 Kubernetes
• 需要 PostgreSQL 的完整功能
• 希望統一管理應用和資料庫
• 團隊有 K8s 經驗

不適合的情況：

• 極端高效能需求（考慮專用硬體）
• 團隊不熟悉 Kubernetes
• 已經有成熟的 DBA 團隊和流程

---

主流 Cloud Native 資料庫比較

關聯式資料庫

PostgreSQL（CloudNativePG）

• 最完整的 SQL 支援
• 豐富的擴充功能
• 適合複雜查詢和交易處理

MySQL（MySQL Operator for Kubernetes）

• Oracle 官方支援
• 適合讀取密集型應用
• 生態系成熟

TiDB

• 分散式 SQL 資料庫
• 相容 MySQL 協定
• 自動水平擴展

CockroachDB

• 分散式、強一致性
• 相容 PostgreSQL 協定
• 適合跨區域部署

NoSQL 資料庫

MongoDB（Percona Operator）

• 文件型資料庫
• Schema 彈性
• 適合快速開發

Cassandra（K8ssandra）

• 寬列型資料庫
• 極高寫入效能
• 適合時間序列資料

Redis（Redis Operator）

• 記憶體資料庫
• 快取首選
• 也可用於訊息佇列

雲端託管 vs 自建

面向	雲端託管（RDS、Cloud SQL）	自建（K8s Operator）
維護負擔	低	中
成本	較高	較低（但需要人力）
彈性	受限於服務功能	完全控制
可移植性	低（雲端鎖定）	高
效能調校	有限	完全控制

比較總表

資料庫	類型	K8s 支援	適用場景
PostgreSQL	關聯式	CloudNativePG	通用、OLTP
MySQL	關聯式	MySQL Operator	讀取密集
TiDB	分散式 SQL	TiDB Operator	大規模 OLTP
CockroachDB	分散式 SQL	原生支援	跨區域
MongoDB	文件型	Percona Operator	快速開發
Cassandra	寬列型	K8ssandra	時間序列
Redis	鍵值型	Redis Operator	快取

資料庫選型太多選擇不知從何下手？預約免費諮詢，讓專家幫你分析需求，推薦最適合的方案。

---

Cloud Native Database 選型決策指南

決策流程

┌─────────────────────────────────────────┐
│  1. 資料模型需求                        │
│  └─ 結構化？文件？鍵值？               │
└──────────────────┬──────────────────────┘
                   │
┌──────────────────▼──────────────────────┐
│  2. 一致性需求                          │
│  └─ 強一致？最終一致？                  │
└──────────────────┬──────────────────────┘
                   │
┌──────────────────▼──────────────────────┐
│  3. 擴展需求                            │
│  └─ 單節點夠嗎？需要分散式？            │
└──────────────────┬──────────────────────┘
                   │
┌──────────────────▼──────────────────────┐
│  4. 團隊能力                            │
│  └─ K8s 經驗？DBA 經驗？               │
└──────────────────┬──────────────────────┘
                   │
┌──────────────────▼──────────────────────┐
│  5. 成本考量                            │
│  └─ 人力成本？基礎設施成本？            │
└─────────────────────────────────────────┘

選型建議

小團隊、快速開發：

• 優先考慮雲端託管服務（RDS、Cloud SQL）
• 減少維運負擔，專注在應用開發

中型團隊、有 K8s 經驗：

• PostgreSQL + CloudNativePG
• 享受 K8s 統一管理的好處

大型企業、需要擴展：

• 評估 TiDB 或 CockroachDB
• 考慮混合方案（關鍵業務用託管、其他自建）

高寫入、時間序列：

• Cassandra + K8ssandra
• 或者專門的時間序列資料庫（TimescaleDB、InfluxDB）

---

在 Kubernetes 上運行資料庫

儲存考量

資料庫最關鍵的是儲存。在 K8s 上要注意：

1. 選擇適當的 StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "10000"
  throughput: "500"
reclaimPolicy: Retain  # 重要！避免誤刪資料
volumeBindingMode: WaitForFirstConsumer

2. 效能測試

用 fio 測試儲存效能，確保符合資料庫需求：

fio --name=random-write --ioengine=posixaio --rw=randwrite \
    --bs=4k --size=1g --numjobs=4 --iodepth=32 --runtime=60 \
    --time_based --end_fsync=1

3. 備份策略

資料庫一定要有備份。Operator 通常支援：

• 定時備份到物件儲存（S3、GCS）
• WAL 歸檔（PostgreSQL）
• 時間點恢復（PITR）

了解更多 K8s 儲存方案？請參考 Cloud Native 技術棧入門。

資源配置

資料庫是資源密集型應用，要適當配置：

spec:
  resources:
    requests:
      memory: "4Gi"
      cpu: "2"
    limits:
      memory: "8Gi"
      cpu: "4"

注意事項：

• 記憶體給夠，避免 OOM
• 避免過度超賣（overcommit）
• 考慮使用 Node Affinity 固定節點

網路配置

資料庫需要穩定的網路連線：

spec:
  template:
    spec:
      dnsPolicy: ClusterFirst
      dnsConfig:
        options:
        - name: ndots
          value: "2"

如果需要外部存取，考慮：

• LoadBalancer Service
• NodePort（測試環境）
• VPN 或私有網路

這也符合 12 Factor 的 Backing Services 原則：資料庫是可抽換的服務。

---

FAQ

Q1: 資料庫真的適合跑在 Kubernetes 上嗎？

視情況而定。如果你的團隊熟悉 K8s，而且資料庫不是極端高效能需求，K8s 是可行的選擇。但如果是核心交易系統，可能還是專用硬體或雲端託管服務更穩妥。

Q2: CloudNativePG 和 Zalando Operator 哪個好？

兩個都很成熟。CloudNativePG 功能較新、有 CNCF 支持。Zalando Operator 有更長的生產驗證歷史。建議根據團隊熟悉度選擇。

Q3: 資料庫容器掛掉資料會不會丟？

不會，如果正確使用 PersistentVolume。資料存在 PV 上，和容器生命週期無關。但一定要設定 reclaimPolicy: Retain。

Q4: 雲端託管和自建哪個划算？

短期來看雲端託管較省事。長期來看，自建可能更省錢，但要計入人力成本。中小團隊建議從託管開始，有經驗後再評估自建。

Q5: 如何從傳統部署遷移到 Cloud Native？

建議漸進式遷移：(1) 先在 K8s 上建新的測試環境 (2) 驗證功能和效能 (3) 設定資料同步 (4) 測試 Failover (5) 切換流量。

---

下一步

Cloud Native Database 讓資料庫管理變得更現代化。建議：

1. 先在開發環境嘗試 CloudNativePG
2. 了解 Operator 的運作方式
3. 規劃備份和災難恢復策略
4. 評估是否適合你的生產環境

延伸閱讀：

• 回到核心概念：Cloud Native 完整指南
• 了解架構原則：12 Factor App 完整解析
• 深入 Kubernetes：Cloud Native 技術棧入門

資料庫架構需要專業建議？預約免費諮詢，讓我們幫你評估現況，規劃最適合的資料庫策略。

---

參考資料

• CloudNativePG Documentation
• CNCF Cloud Native Database Landscape
• Kubernetes Persistent Volumes
• PostgreSQL on Kubernetes
• Zalando Postgres Operator