個人網站怎麼選資料庫 (關聯 非關聯)
個人網站怎麼選資料庫(關聯 vs 非關聯)
TL;DR結構化資料(用戶、訂單、訊息) → 關聯式(SQL):MySQL / PostgreSQL。非結構化或半結構化(文章、log、事件) → NoSQL:MongoDB / Firestore。大型網站常常混用,Medium 就是這樣。2026 年個人網站首選 Supabase(PostgreSQL + Auth + Storage 一站式)。
資料庫兩大陣營
SQL(關聯式)
| 特色 | |
|---|---|
| 資料模型 | Schema 預先定義,table + row + foreign key |
| 查詢 | SQL,支援 JOIN、aggregate、transaction |
| ACID | 強一致性(Atomic / Consistent / Isolated / Durable) |
| 擴展 | 垂直擴展為主(更強的單機) |
| 代表 | MySQL、PostgreSQL、SQLite、SQL Server |
優點:
- 邏輯清晰,符合傳統資料模型
- 一致性 + 完整性保證
- 複雜查詢、多 table JOIN 強
缺點:
- Schema 改動代價高(migration)
- 高併發讀寫需要優化
- 不擅長存非結構化資料(JSON 雖能存但查詢繁瑣)
NoSQL(非關聯式)
| 子類型 | 代表 | 適合 |
|---|---|---|
| Document | MongoDB / Firestore / CouchDB | 文章、商品、半結構化 |
| Key-Value | Redis / DynamoDB | 快取、session |
| Wide-column | Cassandra / HBase | 大量時序資料 |
| Graph | Neo4j / ArangoDB | 關係網路、社群 |
優點:
- Schema flexible,加欄位不用 migration
- 水平擴展容易(分片設計)
- 文件型結構接近 JSON,前端友善
缺點:
- 沒 JOIN 或實作得較弱
- 一致性通常較弱(eventual consistency)
- 複雜查詢要在程式邏輯裡處理
選型決策樹
你的資料 ==結構穩定== 且 ==關係明確==(用戶 → 訂單 → 商品 等)?
├── 是 → SQL(PostgreSQL 或 MySQL)
│
└── 否(資料形狀會變、是文件型、不需 JOIN)?
├── 是 → NoSQL Document(MongoDB / Firestore)
│
└── 是純快取 / KV?
└── Redis
真實世界:常常混用
Medium、Twitter、Instagram 等大型網站都是 多種資料庫並用:
| 資料 | 用途 | 存哪 |
|---|---|---|
| 用戶帳戶、權限、訂閱 | 強一致性、頻繁 JOIN | PostgreSQL |
| 文章內容(HTML / Markdown) | 半結構化、版本多 | MongoDB / S3 |
| 文章索引(全文搜尋) | 反向索引、相似度 | ElasticSearch |
| Session / 快取 | 短期、KV、TTL | Redis |
| 圖片 / 影片 | 大檔案 | S3 / Cloud Storage |
| 即時通知 / WebSocket state | KV + pub/sub | Redis |
個人網站不需要這麼複雜,但理解「不同資料用不同庫」這個 pattern 很重要。
個人網站推薦組合(2026)
全 Firebase(最快上線)
Firestore(NoSQL)+ Firebase Auth + Storage + Hosting
優:零後端、5 分鐘起站、Auth 跟 Storage 整合 劣:Vendor lock-in、查詢能力受限、價格在大量 read 時上升快
Supabase(PostgreSQL + 現代 BaaS)⭐ 我的首選
PostgreSQL + Supabase Auth + Storage + Edge Functions
優:
- SQL 強大,複雜查詢隨意
- Row Level Security(類似 Firestore Rules,但寫 SQL)
- 開源、可自架
- Vercel-style DX
劣:免費額度比 Firebase 嚴格(7 天無活動 project 會被暫停)
Vercel + Postgres / Turso(Edge-first)
Vercel Postgres / Turso(SQLite at edge)+ Vercel Auth
優:邊緣資料庫,延遲超低 劣:還在快速演化,生態未成熟
自架(VPS + Docker)
PostgreSQL + Redis + Caddy + 你寫的 Express/Hono API
優:完全控制、無 vendor lock-in 劣:你要自己負責備份、升級、安全、scaling
我的建議:看「會不會走太遠」
| 情境 | 推薦 |
|---|---|
| 試 idea、不確定會不會做下去 | Firebase / Supabase free tier |
| 確定要做下去、會有付費用戶 | Supabase(SQL 跑得夠遠,需要時自架也容易) |
| 高流量 / 已驗證商業模式 | 自架 PostgreSQL 或 managed RDS / PlanetScale |
| 簡單 portfolio、純展示 | SQLite + Turso,或乾脆 Markdown + Static Site |
個人經驗:Firebase 適合 demo,Supabase 適合 會放著跑很久 的專案。SQL 的查詢能力會在 1 年後感謝自己當初選的。
進階:資料量大時要思考的
當資料量到 幾十萬筆,效能會差別:
1. 索引(Index)
-- PostgreSQL
CREATE INDEX idx_posts_author ON posts(author_id);
CREATE INDEX idx_posts_created ON posts(created_at DESC);
沒索引的 column 做 WHERE 或 ORDER BY 會 full scan,慢到爆。
2. 分頁
-- ❌ OFFSET 越大越慢(每次都從頭算)
SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 10000;
-- ✅ Cursor-based(用上一頁最後一筆的 ID 當錨點)
SELECT * FROM posts WHERE created_at < '2026-05-09 10:00:00'
ORDER BY created_at DESC LIMIT 20;
3. 快取
熱資料(首頁、熱門文章)放 Redis,DB 只查冷資料。Vercel Edge Cache、Cloudflare KV 也是現代的選項。
4. 讀寫分離 / Replica
主庫寫,從庫讀,分散負載。Supabase / RDS 都支援。
常見錯誤(個人網站階段)
Over-engineering個人網站 100 個用戶不需要分庫、分表、Sharding。過早優化是萬惡之源。先用 Supabase / Firebase 跑起來,有問題再說。
Schema 設計太死板用 SQL 不代表要設計到完美第三正規化。留一個 metadata JSONB 欄位放彈性資料,等模式穩定再 migration。PostgreSQL 的 JSONB 又快又能 index,是 SQL+NoSQL 的最佳兩端。
-- PostgreSQL JSONB 欄位
CREATE TABLE posts (
id SERIAL PRIMARY KEY,
title TEXT NOT NULL,
content TEXT,
author_id UUID,
metadata JSONB DEFAULT '{}', -- ⭐ 彈性欄位
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- 查 metadata 內某個 key
SELECT * FROM posts WHERE metadata->>'category' = 'tech';
CREATE INDEX idx_metadata ON posts USING GIN (metadata); -- 可索引!