SQLite 不是玩具，只是你沒用對 WAL

生產環境的併發問題，不是 SQLite 的問題

很多人說 SQLite 不適合生產環境，理由通常是「併發鎖定」。但這忽略了一個細節：SQLite 的預設配置是為了簡單性，不是為了併發。打開 WAL（Write-Ahead Logging）模式，情況就完全不同了。

WAL 的邏輯很直白——寫入不再直接修改主資料庫檔案，而是先寫到日誌檔案。讀取可以並行進行，因為讀者看的是已提交的版本，寫者在日誌裡工作。這個設計在 SQLite 3.7.0（2010 年）就有了，但很多人至今沒用上。

你遇到的「SQLite 鎖定問題」可能只是配置問題。

多資料庫分離是實務折衷

即使開啟 WAL，SQLite 還是單一進程的設計。如果併發寫入真的很密集，WAL 也會遇到瓶頸——同一時間只有一個寫者能提交。

實務做法是不要用一個龐大的 SQLite 檔案。改成多資料庫分離——按租戶、按時間、或按功能域拆分資料庫檔案。每個檔案獨立的 WAL 日誌，寫入競爭自然下降。這不是什麼高深的架構，只是承認了一個事實：單一檔案的吞吐量有天花板，但多個檔案的總吞吐量是線性擴展的。

這個折衷的成本很低。你不需要改動應用層的查詢邏輯太多，只是在連接層多加一層路由。

什麼時候不該用 SQLite

有些場景 SQLite 確實不適合：

• 跨地域複製。SQLite 沒有原生的分散式複製機制，如果你需要主從同步或多資料中心，PostgreSQL 或 MySQL 會更直接。
• 超大規模單表。單一表的行數達到億級時，SQLite 的索引效率會明顯下降。不是不能用，但你會開始感受到它的邊界。
• 複雜的分析查詢。SQLite 的查詢優化器不如企業級資料庫激進，大型 JOIN 或聚合會比較慢。

但這些都不是 SQLite 的設計缺陷，只是它的設計目標本來就不在那裡。

判斷標準其實很簡單

成功案例通常有幾個共通點：清楚自己的併發模式（量化過的，不是「可能會很高」）、願意在配置上花時間而不是用預設值上線、把 SQLite 當作一個有邊界的工具，而不是試圖把它當 PostgreSQL 用。

如果你的系統每秒寫入量在三位數以內，資料量在 GB 級別，不需要跨地域複製，那 SQLite + WAL + 多資料庫分離這個組合值得認真考慮。部署簡單，運維成本低，備份就是複製檔案。

反過來，如果你還在用預設配置然後抱怨鎖定，那問題不在 SQLite，在你沒讀文件。

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。

原始來源：https://ultrathink.art/blog/sqlite-in-production-lessons