跳到主要內容
← 回到學習

學習 · 後端與資料庫

個人網站怎麼選資料庫 (關聯 非關聯)

By Kurau7 分鐘閱讀

目錄 · 7 個段落
  1. 01資料庫兩大陣營
  2. 02選型決策樹
  3. 03真實世界:常常混用
  4. 04個人網站推薦組合(2026)
  5. 05我的建議:看「會不會走太遠」
  6. 06進階:資料量大時要思考的
  7. 07常見錯誤(個人網站階段)

個人網站怎麼選資料庫(關聯 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(非關聯式)

子類型代表適合
DocumentMongoDB / Firestore / CouchDB文章、商品、半結構化
Key-ValueRedis / DynamoDB快取、session
Wide-columnCassandra / HBase大量時序資料
GraphNeo4j / ArangoDB關係網路、社群

優點:

  • Schema flexible,加欄位不用 migration
  • 水平擴展容易(分片設計)
  • 文件型結構接近 JSON,前端友善

缺點:

  • 沒 JOIN 或實作得較弱
  • 一致性通常較弱(eventual consistency)
  • 複雜查詢要在程式邏輯裡處理

選型決策樹

你的資料 ==結構穩定== 且 ==關係明確==(用戶 → 訂單 → 商品 等)?
├── 是 → SQL(PostgreSQL 或 MySQL)
│
└── 否(資料形狀會變、是文件型、不需 JOIN)?
    ├── 是 → NoSQL Document(MongoDB / Firestore)
    │
    └── 是純快取 / KV?
        └── Redis

真實世界:常常混用

Medium、Twitter、Instagram 等大型網站都是 多種資料庫並用:

資料用途存哪
用戶帳戶、權限、訂閱強一致性、頻繁 JOINPostgreSQL
文章內容(HTML / Markdown)半結構化、版本多MongoDB / S3
文章索引(全文搜尋)反向索引、相似度ElasticSearch
Session / 快取短期、KV、TTLRedis
圖片 / 影片大檔案S3 / Cloud Storage
即時通知 / WebSocket stateKV + pub/subRedis

個人網站不需要這麼複雜,但理解「不同資料用不同庫」這個 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);
sql

沒索引的 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;
sql

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);  -- 可索引!
sql

目錄