背景

KeePass 長期以來被視為密碼管理的金標準，其核心的 KDBX 格式自 2007 年起便基於加密且壓縮的 XML 檔案。然而，隨著現代安全需求如 TOTP 與通行密鑰（Passkeys）的出現，這種格式在擴展性與儲存效率上的侷限性引發了討論，部分開發者主張應轉向以 SQLite 為基礎的架構，以解決架構僵化與大檔案效能低下的問題。

社群觀點

針對將 KDBX 格式遷移至 SQLite 的提議，Hacker News 社群展開了激烈的辯論。支持者認為 SQLite 的頁面級寫入特性（Page-level granularity）能有效解決目前 KDBX 每次修改都必須重寫整個檔案的弊端，這對於儲存大量附件或自定義圖示的用戶尤為重要，能避免因網路不穩導致的檔案損壞。此外，支持者指出目前的 XML 結構導致各家客戶端在實作新功能時，往往將數據塞入自定義屬性中，形成一種混亂的「影子架構」，若能藉此機會統一標準並建立更民主的治理結構，將有利於生態系的長遠發展。

然而，反對聲音同樣強大且具備說服力。許多資深用戶與開發者指出，KDBX 採用的「全檔案加密與驗證」實際上是一種安全特性而非缺陷。若改用 SQLite 或 SQLCipher 等分段加密方案，雖然提升了寫入效率，卻可能洩漏檔案結構的變動資訊，甚至增加局部數據被竄改或回滾的風險。對於多數密碼庫僅有數百 KB 的用戶而言，XML 的讀寫開銷幾乎可以忽略不計，且「寫入新檔後替換舊檔」的原子性操作在同步情境下反而比資料庫鎖定機制更為可靠。

部分留言者進一步質疑，技術格式的更迭並不能解決社群治理或標準不一的問題。他們認為 XML 本身就具備極強的擴展性，目前的相容性困境源於開發者之間缺乏溝通，而非格式本身的限制。若強行推動格式轉換，可能會導致現有眾多第三方客戶端（如行動端 App）因開發成本過高而停擺，進而造成生態系的分裂。也有觀點提出折衷方案，例如參考 7zip 或現代 ZIP 容器格式，在保留檔案結構透明度的同時，優化二進位附件的儲存效率。

最後，社群中也出現了對密碼管理本質的思考。有人認為密碼管理器的核心應是簡潔與安全，而非成為全能的秘密檔案庫。如果用戶需要儲存數百 MB 的掃描文件，或許應該使用專門的加密磁碟工具而非強求密碼管理器轉型。這場討論反映了技術社群在追求現代化便利性與堅持傳統安全哲學之間的拉鋸。

延伸閱讀

在討論中被提及的相關工具與資源包括：

• VaultWarden：Bitwarden 的第三方伺服器實作，支援 SQLite 或 Postgres 後端。
• SQLCipher：SQLite 的加密擴充版本，常被用於需要資料庫級加密的應用。
• CodeBook：由 SQLCipher 開發者推出的密碼管理器，採用資料庫儲存架構。
• KeePass Tusk：一個已停止維護的瀏覽器端實作，其開發者在討論中分享了維護 KDBX 規格的挑戰。