你有沒有想過，你每天打開的瀏覽器、手機裡的通訊軟體、甚至桌面上的筆記工具，裡面都藏著同一個輕巧的資料庫？
它不需要你安裝任何伺服器軟體，不需要設定帳號密碼，甚至不需要網路連線。它就是一個 檔案，靜靜地躺在你的硬碟裡，隨時準備好為你服務。
這個低調的存在，就是 SQLite。
什麼是 SQLite？世界上部署最廣泛的資料庫
SQLite 是一個用 C 語言撰寫的 嵌入式關聯式資料庫引擎。
它沒有獨立的伺服器程式，而是直接嵌入你的應用程式中運作。
這跟你熟悉的 PostgreSQL 或 MySQL 完全不同。傳統資料庫是一台 獨立運作的伺服器，你的程式必須透過 網路協定（TCP/IP） 去跟它「通訊」。
但 SQLite 不一樣，它就是一段程式碼，直接跑在你的應用程式裡面，讀寫硬碟上的那個 .db 檔案。
| 比較維度 | SQLite（嵌入式） | PostgreSQL（Client-Server） |
|---|---|---|
| 運作方式 | 直接嵌入應用程式，無獨立伺服器 | 獨立伺服器程式，透過網路連線 |
| 設定需求 | 零設定，免安裝、免帳密 | 需要安裝、設定帳號密碼與防火牆 |
| 資料儲存 | 單一跨平台檔案 | 伺服器目錄下的多個檔案 |
| 備份方式 | 直接複製那個檔案 | 需要使用 pg_dump 等專用工具 |
正因為這種 「隨插即用」 的特性，SQLite 成為了世界上部署最廣泛的資料庫引擎。
從 Android 和 iOS 作業系統、Chrome 和 Firefox 瀏覽器，到 Adobe Lightroom、WhatsApp，甚至是 Airbus A350 的飛行系統，處處都有它的身影。
在 Node.js 中使用 SQLite
如果你是 Node.js 開發者，使用 SQLite 非常簡單。你不需要在電腦上安裝任何資料庫伺服器軟體，只需要安裝一個 npm 套件就能開始。
目前業界最常用的選擇：
| 套件名稱 | 特點 | 建議情境 |
|---|---|---|
sqlite3 |
最老牌，支援非同步 API | 需要大量同時處理多個非同步任務 |
better-sqlite3 |
效能極佳，API 設計直覺，速度極快 | 首選推薦，追求開發效率與執行速度 |
用 better-sqlite3 建立資料庫並查詢，不用五分鐘就能完成：
const Database = require('better-sqlite3');
const db = new Database('my_project.db');
db.prepare('CREATE TABLE IF NOT EXISTS users (name TEXT, age INTEGER)').run();
const insert = db.prepare('INSERT INTO users (name, age) VALUES (?, ?)');
insert.run('John', 25);
const user = db.prepare('SELECT * FROM users WHERE name = ?').get('John');
console.log(user); // { name: 'John', age: 25 }
如果檔案不存在，
better-sqlite3會 自動幫你建立。
SQLite 支援的 SQL 語法比你想的強大
很多人以為 SQLite 很陽春，但它支援絕大多數的標準 SQL 語法，包含許多進階功能：
| 語法類別 | 支援項目 |
|---|---|
| 基礎操作 | SELECT、INSERT、UPDATE、DELETE |
| 資料定義 | CREATE TABLE、CREATE INDEX、CREATE VIEW |
| 進階查詢 | WITH （CTE 遞迴查詢）、視窗函數（Window Functions） |
| 衝突處理 | UPSERT （INSERT ... ON CONFLICT DO UPDATE） |
| JSON 處理 | json_extract、json_array、json_object 等內建函數 |
| 交易控制 | BEGIN、COMMIT、ROLLBACK、SAVEPOINT |
| 連接查詢 | INNER JOIN、LEFT JOIN、RIGHT JOIN 和 FULL OUTER JOIN |
SQLite 的核心哲學是「小而美」，它支援多數你日常需要的 SQL 能力，同時保持極致的輕量。
SQLite 的極限在哪？
輕巧是有代價的。如果把 SQLite 比喻為一間 只有一個結帳櫃檯的文青雜貨店，那 PostgreSQL 就是 配備 50 個收銀台的好市多。
1. 寫入大塞車
SQLite 在寫入資料時，會把整個資料庫檔案 鎖起來。
想像一間 只有一間廁所的餐廳：100 個人可以同時在外面看菜單（讀取），但只要有 1 個人進去把門鎖上（寫入），其他人就只能排隊等。
雖然開啟 WAL 模式 （Write-Ahead Logging） 能改善讀寫並行的效能，但本質上仍然無法做到多執行緒同時寫入不同的資料行。
2. 無法跨多台伺服器
SQLite 的本質就是一個實體檔案。如果你的系統部署在多台伺服器上（水平擴展），這些伺服器 無法安全地共用同一個檔案。
3. 缺乏精細的權限管理
SQLite 沒有「使用者帳號」的概念。誰能在作業系統層面讀取那個 .db 檔案，誰就能看光、修改所有資料。
對於 需要嚴格個資審查的商務系統，這是無法接受的。
SQLite vs. PostgreSQL：技術選型決策
工具沒有好壞，只有適不適合。以下是一份幫助你做決策的終極檢核表：
| 提問 | 答「是」→ 選 SQLite | 答「否」→ 選 PostgreSQL |
|---|---|---|
| 後端伺服器是不是只有一台，或完全跑在本機端？ | 是 | 否（有水平擴展、多台機器） |
| 系統行為是不是讀遠遠大於寫，且沒有高頻並行寫入？ | 是 | 否（大家會同時搶著寫入） |
| 不需要精細的資料庫帳號權限或進階索引？ | 是 | 否（極度依賴進階功能） |
更具體的情境對照：
| 情境 | 推薦選擇 | 理由 |
|---|---|---|
| 桌面軟體、手機 App、IoT 裝置 | SQLite | 資料跟著設備走，免安裝 |
| 個人部落格、展示型官網 | SQLite | 讀多寫少，省去維護伺服器成本 |
| 快速原型開發、Demo | SQLite | 建個檔案就能開工 |
| 社群論壇、電商平台 | PostgreSQL | 高併發寫入，需要行級鎖 |
| 多台伺服器分散部署 | PostgreSQL | 需要跨機器共享資料源 |
| 醫療、金融等敏感系統 | PostgreSQL | 需要嚴格的角色權限控管 |
你的資料庫是隨身筆記還是中央總機
如果資料是 「單機、靜態、單一擁有者」，選 SQLite 享受極致的輕量與自由；
如果資料是 「雲端、動態、高度互動」，讓 PostgreSQL 接管。
SQLite 的核心哲學是 「應用程式的內部元件」，而 PostgreSQL 的定位是 「系統架構的獨立中樞」。
下次在架構決策時，別急著拿出 PostgreSQL，先問問自己：
「我的資料庫，是拿來當隨身筆記，還是中央總機？」
答案清楚了，選擇自然就明確了。