結論先講
如果你不確定要用什麼資料庫，先用 PostgreSQL。 不是開玩笑——PG 在 2026 年已經能搞定關聯式、JSON 文件、全文搜尋、向量搜尋，甚至時序資料。但如果你的場景有明確的特殊需求（每秒百萬寫入、圖形關聯查詢、亞毫秒快取），那你需要看完這張全景圖。
「沒有最好的資料庫，只有最適合的。」這句話是正確的廢話。這篇的目標是讓你知道什麼場景適合什麼。
一張表看懂所有資料庫類型
| 類型 | 代表產品 | 資料模型 | 最佳使用場景 | 不適合 |
|---|---|---|---|---|
| 關聯式 (RDBMS) | MySQL, PostgreSQL, MariaDB | 表格 + 關聯 | CRUD、交易處理、結構化資料 | 非結構化大量資料 |
| 文件式 (Document) | MongoDB, Firestore | JSON/BSON 文件 | 彈性 Schema、快速迭代 | 複雜跨集合 JOIN |
| 鍵值 (Key-Value) | Redis, DynamoDB, Valkey | Key → Value | 快取、Session、排行榜 | 複雜查詢、範圍搜尋 |
| 列族 (Column-Family) | Cassandra, HBase, ScyllaDB | 寬列存儲 | 超大規模寫入、時序 | 複雜查詢、小型應用 |
| 圖形 (Graph) | Neo4j, Amazon Neptune | 節點 + 邊 | 社交網路、推薦系統、知識圖譜 | 簡單 CRUD |
| 時序 (Time-Series) | InfluxDB, TimescaleDB | 時間戳 + 指標 | IoT、監控、金融行情 | 通用型 CRUD |
| 搜尋引擎 | Elasticsearch, Meilisearch | 倒排索引 | 全文搜尋、日誌分析 | 當主資料庫 |
| 向量 (Vector) | Pinecone, Chroma, pgvector | 高維向量 | AI/ML 語義搜尋、RAG | 精確匹配查詢 |
| NewSQL | CockroachDB, TiDB, YugabyteDB | 關聯式 + 分散式 | 需要 SQL + 水平擴展 | 簡單小型應用（太重） |
| 嵌入式 | SQLite, DuckDB | 檔案型 | 行動 App、CLI 工具、分析 | 高並發多寫入 |
每種類型深入看
關聯式資料庫 (RDBMS)
老大哥，穩定、成熟、ACID 保證。2026 年還是最主流的選擇。
-- 關聯式的強項：複雜 JOIN + 交易
BEGIN;
UPDATE accounts SET balance = balance - 1000 WHERE id = 1;
UPDATE accounts SET balance = balance + 1000 WHERE id = 2;
INSERT INTO transfers (from_id, to_id, amount) VALUES (1, 2, 1000);
COMMIT;選誰？
- PostgreSQL：功能最全，2026 年新專案的預設選擇
- MySQL：PHP 生態（WordPress）、讀取效能好
- MariaDB：MySQL 的社群分支，相容但更開放
文件式資料庫 (Document)
Schema 彈性是最大的優勢。同一個 Collection 裡的文件可以有不同的欄位。
// MongoDB：不需要先定義 Schema
db.products.insertOne({
name: "機械鍵盤",
price: 3500,
specs: {
switches: "Cherry MX Brown",
layout: "75%",
rgb: true
},
tags: ["keyboard", "mechanical", "office"]
});什麼時候用？ 產品目錄（每個商品屬性不同）、CMS 內容、快速原型開發。
什麼時候不用？ 你需要跨集合 JOIN、需要嚴格的資料一致性、或者你的資料其實很結構化——那直接用 RDBMS。
鍵值資料庫 (Key-Value)
最簡單的模型：一個 key 對一個 value。速度極快。
import redis
r = redis.Redis()
# 快取 API 回應，60 秒過期
r.setex("user:1234:profile", 60, json.dumps(user_data))
# 讀取
cached = r.get("user:1234:profile")Redis 是這類的王者。 但要注意：Redis 的資料預設放在記憶體，成本比磁碟高很多。DynamoDB 走的是不同路線——它是磁碟型的鍵值庫，適合需要持久化的場景。
圖形資料庫 (Graph)
當你的資料關係比資料本身重要時。
// Neo4j Cypher 查詢：找出共同朋友
MATCH (a:Person {name: "Alice"})-[:FRIEND]->(mutual)<-[:FRIEND]-(b:Person {name: "Bob"})
RETURN mutual.name六度分隔、推薦引擎、反詐欺偵測——這些場景用 SQL 寫會是幾百行的遞迴 CTE，用 Graph DB 三行搞定。但如果你的關聯很簡單（外鍵 JOIN 就夠），不需要上 Graph DB。
時序資料庫 (Time-Series)
專門為「時間戳 + 數值」的寫入模式最佳化。
-- TimescaleDB（基於 PostgreSQL 的擴展）
SELECT time_bucket('1 hour', time) AS hour,
avg(temperature) AS avg_temp,
max(temperature) AS max_temp
FROM sensor_data
WHERE time > now() - interval '7 days'
GROUP BY hour
ORDER BY hour;InfluxDB 用自己的查詢語言（Flux），TimescaleDB 直接用 SQL（因為它是 PG 擴展）。如果你已經用 PG，TimescaleDB 的入門門檻低很多。
搜尋引擎
本系列 第 05 篇 會深入講。簡單說：
- Elasticsearch：功能最強、生態最大，但重、吃資源
- Meilisearch：輕量、容錯搜尋、開發者體驗好
- PostgreSQL 內建：小量資料 +
pg_trgm就夠了
向量資料庫 (Vector DB)
2024–2026 年最火的新類別，因為 AI/LLM 需要語義搜尋。
# 使用 pgvector（PostgreSQL 擴展）
# 存入向量
cursor.execute("""
INSERT INTO documents (content, embedding)
VALUES (%s, %s)
""", (text, embedding_vector))
# 語義搜尋：找最相似的 5 筆
cursor.execute("""
SELECT content, embedding <=> %s AS distance
FROM documents
ORDER BY distance
LIMIT 5
""", (query_vector,))專用 vs 擴展：
- Pinecone / Weaviate：專用服務，大規模效能好
- Chroma：輕量、Python 生態
- pgvector：PG 擴展，不用多維護一個資料庫
如果你的向量資料不超過幾百萬筆，pgvector 通常就夠了。
NewSQL
想要 SQL 的一切 + 自動水平擴展。
- CockroachDB：Google Spanner 的開源版，強一致性
- TiDB：PingCAP 開發，相容 MySQL 協定
- YugabyteDB：相容 PostgreSQL 協定
什麼時候需要？ 你的資料量和流量大到單台 RDBMS 撐不住，但又不想放棄 SQL 和 ACID。大部分應用不需要。
嵌入式資料庫
不需要啟動伺服器，資料庫就是一個檔案。
- SQLite：用在手機 App、Electron、CLI 工具、測試。全世界部署量最大的資料庫
- DuckDB：專為分析設計的嵌入式 OLAP，可以直接查 CSV/Parquet
# DuckDB 直接查 CSV 檔
duckdb -c "SELECT category, count(*) FROM 'sales.csv' GROUP BY category"決策流程圖
遇到選型問題，先問自己這些問題：
你的資料有固定結構嗎？
├── 是 → 需要水平擴展嗎？
│ ├── 是 → NewSQL (CockroachDB / TiDB)
│ └── 否 → PostgreSQL（幾乎萬用）
├── 否 → 資料是什麼類型？
│ ├── JSON 文件 → MongoDB / Firestore
│ ├── 快取/Session → Redis
│ ├── 時序數據 → TimescaleDB / InfluxDB
│ ├── 全文搜尋 → Elasticsearch / Meilisearch
│ ├── 向量/語義 → pgvector / Pinecone
│ ├── 關係圖譜 → Neo4j
│ └── 超大規模寫入 → Cassandra / ScyllaDB
└── 不確定 → PostgreSQL（先開始，之後再拆）
注意最後一行。很多時候你不需要提前決定所有事——先用 PG，等遇到瓶頸再引入專用資料庫。
「直接用 PostgreSQL」的論點
這幾年有一派聲音越來越大：「PostgreSQL 是唯一你需要的資料庫。」
為什麼？
| 需求 | PostgreSQL 的解法 |
|---|---|
| JSON 文件 | JSONB + GIN 索引 |
| 全文搜尋 | tsvector + pg_trgm |
| 向量搜尋 | pgvector |
| 時序資料 | TimescaleDB 擴展 |
| GIS 地理 | PostGIS |
| 訊息佇列 | LISTEN/NOTIFY + SKIP LOCKED |
什麼時候這是對的？
- 你是小到中型團隊，維護一個資料庫就夠忙了
- 你的每個需求都不是超大規模
- 你不想學 5 種不同的查詢語言
什麼時候不該這樣做？
- 你需要亞毫秒回應（Redis 快取還是要的）
- 你的搜尋需要處理百萬筆文件 + 複雜分詞（Elasticsearch 更適合）
- 你的向量資料超過千萬筆（專用 Vector DB 效能差距會很明顯）
- 你需要嵌入式資料庫（SQLite / DuckDB）
CAP 定理：30 秒版
分散式系統最多只能同時滿足三者中的兩個：
- C (Consistency)：所有節點看到一樣的資料
- A (Availability)：每個請求都能得到回應
- P (Partition Tolerance)：網路分割時系統還能運作
因為網路分割是一定會發生的（P 不可選），所以實際上是在 CP 和 AP 之間選：
| 選擇 | 代表 | 行為 |
|---|---|---|
| CP | PostgreSQL, CockroachDB, MongoDB (多數決) | 網路出問題時寧可拒絕服務也不回傳舊資料 |
| AP | Cassandra, DynamoDB, CouchDB | 網路出問題時還是回應，但資料可能不是最新的 |
對大多數 Web 應用來說，CP 是你要的。 AP 適合寫入量極大、允許短暫不一致的場景（例如社群按讚數、IoT 感測器資料）。
延伸閱讀
如果你想從基礎架構的角度理解資料庫選型，可以看 基礎架構系列的資料庫全景篇。那篇著重在部署、維運、雲端服務的角度，和這篇是互補的。
常見問題
新手該先學哪個資料庫？
PostgreSQL。 它嚴格、標準、功能全。學會 PG 之後再學其他資料庫會很快，反過來（先學 MySQL 的寬鬆模式再去 PG）會很痛苦。
NoSQL 是不是比 SQL 快？
不一定。NoSQL 在特定場景快（Redis 的記憶體讀取、Cassandra 的大量寫入），但在通用查詢上，調校好的 PostgreSQL 不輸 MongoDB。「NoSQL 比較快」是 2010 年代的行銷話術。
可以在一個專案裡用多個資料庫嗎？
可以，很多公司都這樣做。典型組合：PostgreSQL（主資料庫）+ Redis（快取）+ Elasticsearch（搜尋）。但每多一個就多一份維運負擔，不要為了潮而加。
什麼是 Polyglot Persistence？
就是在一個系統裡用多種資料庫，各取所長。聽起來很美，但維運成本是真的。三人團隊通常一個 PG + 一個 Redis 就是極限了。
Vector DB 是不是一時的炒作？
不是。AI/LLM 的 RAG（Retrieval-Augmented Generation）架構確實需要向量搜尋，而且這個需求只會越來越大。但不代表你一定要用專用的 Vector DB——pgvector 對大多數場景已經夠用。