你真的需要資料庫嗎？

背景

這篇文章源自 DB Pro 團隊的技術部落格，探討在現代開發環境中，開發者是否過度依賴資料庫管理系統（DBMS）。作者透過 Go、Rust 與 Bun 實作了從簡單的文件掃描到記憶體映射，再到二進位搜尋等不同層次的儲存策略，並與 SQLite 進行效能對比，指出對於許多初創項目而言，直接操作檔案系統往往能提供更優異的效能與更低的複雜度。

社群觀點

Hacker News 的討論呈現出明顯的兩極化趨勢。支持者認為現代硬體效能，特別是 NVMe 硬碟與作業系統的分頁快取（Page Cache），已經強大到足以讓簡單的 JSONL 檔案應付絕大多數初創企業的初期需求。有評論指出，許多開發者在產品還沒人使用時，就急於部署 Kubernetes、Redis 與託管式 PostgreSQL，這種「過度工程」往往消耗了寶貴的開發資源與雲端預算。他們認為，一個簡單的 Go 二進位檔配合純文字儲存，其生命週期可能比大多數新創公司的資金鏈還要長。

然而，反對意見則強調「資料庫」與「資料庫管理系統（DBMS）」之間的本質區別。許多資深工程師警告，雖然手寫二進位搜尋在讀取效能上可能超越 SQLite，但開發者很快就會面臨原子性寫入、併發控制、備份恢復、架構遷移（Schema Migration）以及資料損壞等棘手問題。若為了避開資料庫而自行實作這些功能，最終只會得到一個功能殘缺、未經充分測試且充滿臭蟲的「劣質版 SQLite」。他們主張 SQLite 本身已經極其輕量且效能卓越，甚至在某些場景下比直接操作檔案更快，實在沒有理由為了省下極小的開銷而放棄其提供的強大保障。

此外，討論中也觸及了技術選型的文化問題。有觀點認為，選擇 NoSQL 或純檔案儲存往往是為了規避資料建模的思考，但隨著業務增長，缺乏關聯性與約束的資料最終會變成難以維護的混亂堆疊。更有趣的補充觀點提到，對於某些特定場景，如靜態網站或 PDF 處理工具，完全「無狀態」或使用純靜態 JSON 確實是最佳解。而針對極大規模的需求，甚至有開發者為 Oracle 等傳統巨頭辯護，認為其自動化索引與 JSON 雙重性視圖在長期維護成本上，反而可能低於自行拼湊的開源解決方案。

綜合來看，社群的共識傾向於：雖然技術上可以不使用資料庫，但除非是極其單純的唯讀場景或學習實驗，否則在生產環境中，選擇像 SQLite 這樣經過數十年驗證的工具，通常是比「重新發明輪子」更明智且具備成本效益的決策。

延伸閱讀

在討論串中，參與者推薦了幾項值得關注的資源與工具。針對 Python 開發者，有人推薦使用 diskcache 作為檔案基礎的快取方案。在效能對比方面，SQLite 官方文件中的「SQLite 運作速度快於檔案系統」一文被多次引用，用以平衡文章中的測試結果。此外，Joe Armstrong 於 2014 年撰寫的《最小可行程式》（Minimum Viable Programs）以及探討關聯式資料庫生命力的文章《關聯式資料庫不是恐龍，而是鯊魚》也被提及，作為反思軟體架構簡約性的參考。