結論先講
如果只能選一個 DB，選 PostgreSQL。 不是因為它每個場景都贏（MySQL 寫入快 2.5 倍），而是因為 JSONB 讓你不用額外維護 MongoDB、extension 生態讓你不用額外加 Elasticsearch（小規模時）、replication 設定比 MySQL 簡單。一個 DB 能做三個 DB 的事，維護成本低。
壓測數據回顧
第 17 篇 的數據：
| 場景 | PG | MySQL | 贏家 |
|---|---|---|---|
| 一般 CRUD（50:50） | 197 RPS | 183 RPS | PG +8% |
| JSON 查詢 | 645 RPS | 201 RPS | PG 3.2 倍 |
| 寫入密集（20:80） | 199 RPS | 498 RPS | MySQL 2.5 倍 |
| Transaction 鎖競爭 | 高 40% | 基準 | PG |
但壓測只測了「速度」。選 DB 還要看：
速度之外的五個考量
1. JSONB：省掉一個 MongoDB
PG 的 JSONB 支援 GIN 索引——查 JSON 欄位走索引，不用全表掃描。
-- PG：直接查 JSON 欄位，走 GIN 索引
SELECT * FROM products WHERE specs @> '{"color": "red"}';
-- MySQL：JSON_EXTRACT 不走索引（5.7），要用 generated column + index
SELECT * FROM products WHERE JSON_EXTRACT(specs, '$.color') = 'red';Storage 篇 的數據：PG JSONB 和 MongoDB 存 JSON 的速度只差 4%。
意味著：中小型應用不需要額外維護一個 MongoDB。 商品規格、用戶設定、表單動態欄位——全部用 PG JSONB 搞定。少一個服務 = 少一份部署、監控、備份、升級的成本。
2. VACUUM：PG 的隱藏維護成本
PG 的 MVCC 在每次 UPDATE/DELETE 時產生舊版本的 row（dead tuple）。VACUUM 負責清理這些垃圾。
小規模（< 100 萬筆）: autovacuum 預設設定就夠，你幾乎感覺不到。
大規模（> 1000 萬筆 + 高頻寫入）: 需要調 autovacuum 的觸發頻率和 worker 數量。否則 dead tuple 堆積 → 表膨脹 → 查詢變慢 → 磁碟空間爆掉。
MySQL 的 InnoDB 也有類似機制（undo log + purge），但 MySQL 的 purge 比 PG 的 VACUUM 輕量——這就是為什麼 MySQL 在寫入密集場景快 2.5 倍。
結論：如果你的場景是「瘋狂寫入、很少讀取」（IoT 數據、日誌收集），MySQL 真的比較適合。
3. Replication：PG 更簡單
| 功能 | PostgreSQL | MySQL |
|---|---|---|
| 主從複製 | Streaming Replication（內建） | binlog replication（內建） |
| 邏輯複製 | Logical Replication（PG 10+） | binlog + row-based |
| 延遲 | 通常 < 1 秒 | 通常 < 1 秒 |
| 設定複雜度 | 低（幾行 config） | 中（需要 GTID 設定） |
| 故障切換 | Patroni / pg_auto_failover | MHA / Orchestrator |
PG 的 streaming replication 設定非常簡單——改幾行 postgresql.conf 和 pg_hba.conf 就好。MySQL 的 replication 需要 binlog 格式、server-id、GTID 等更多配置。
4. Extension 生態
PG 有豐富的 extension，很多功能不用額外裝服務：
| 需求 | PG Extension | 替代方案 |
|---|---|---|
| 全文搜尋 | pg_trgm + tsvector | Elasticsearch |
| 地理資訊 | PostGIS | MongoDB geospatial |
| 時序資料 | TimescaleDB | InfluxDB |
| 向量搜尋 | pgvector | Pinecone / Milvus |
| 任務排程 | pg_cron | 外部 cron |
pgvector 在 2026 年特別重要——AI 應用需要向量搜尋，用 PG + pgvector 就能做 RAG，不需要額外維護 Pinecone。
MySQL 的 plugin 生態比較薄。
5. 社群趨勢
Stack Overflow 2025 調查、DB-Engines Ranking、GitHub star 趨勢都顯示：PG 在過去 5 年持續上升，MySQL 持平。 新的框架和工具越來越以 PG 為優先支援。
什麼時候選 MySQL
MySQL 不是不好。有三個場景它明確勝出：
- 寫入密集：日誌、IoT、事件紀錄。壓測數據 2.5 倍差距不是假的
- 團隊熟悉：如果團隊 10 年 MySQL 經驗，換 PG 的學習成本可能不值得
- 現有系統遷移成本太高：幾百張表、幾百個 stored procedure，遷移風險大於收益
下一篇
從 MySQL 遷移到 PostgreSQL：實戰踩坑指南 — 如果你決定換，怎麼做最安全？schema 差異、資料型態對照、ORM 層的改動、遷移工具選擇。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：壓測教會我的事：如果重來一次 → 下一篇：從 MySQL 遷移到 PostgreSQL：實戰踩坑指南