February 24, 2026
Tiny file, giant fight
Why the KeePass format should be based on SQLite
KeePass fans clash: ‘Use SQLite’ vs ‘Leave XML alone’
TLDR: A post says KeePass should ditch its encrypted XML file for SQLite to make new features cleaner. Commenters fire back that files are small, this is an implementation problem, and backward compatibility wins—plus jokes about “cursory” versus database cursors—so the format war rages on.
KeePass, the cult-favorite password vault, just stoked a format feud: a viral post argues the current encrypted XML file (KDBX) is too brittle and messy, cramming things like two‑factor codes and passkeys into random “extra fields.” The fix? Move the whole thing to SQLite, a simple file‑based database, so new features get a proper home and the app stops rewriting the entire file for tiny changes. Sounds clean… until the community showed up with receipts.
Cue Team XML vs Team SQLite. One camp says the “rewrite the whole file” gripe is an implementation issue, not a format problem, while others note their vaults are tiny anyway—“under 100K,” flexes one user—so who cares. Backward compatibility gets framed as the real hill to die on: don’t break a trusted system for shiny new tables, warns a chorus of power users. Another skeptic snarks that everything proposed is “perfectly possible with XML,” and SQLite is optimized for stuff that “doesn’t matter for password storage.” Meanwhile, the thread spawned memes and a mini‑conspiracy: someone riffed on “cursory (lol, get it?)” and asked if the post was AI‑written, turning a database debate into a vibe check. The verdict? The tech is secondary—the drama is the main feature KeePass KeePassXC SQLite
Key Points
- •KDBX 4.1 stores KeePass data as an encrypted and authenticated gzipped XML file; updates rewrite and load the entire file into memory.
- •KDBX relies on TProtectedString (user-facing) and CustomData (plugin/app) for extensibility, leading to attributes holding many features.
- •TOTP support emerged via plugins with inconsistent attribute names and parameters; KeePassXC adopted an otpauth URI, while KeePass Proper used TimeOtp-Secret.
- •Passkey support was first implemented by StrongBox, coordinated with KeePassXC, and initially had brief incompatibility; it adds multiple user-facing attributes.
- •The article argues that the XML schema’s brittleness causes cross-client compatibility issues and proposes SQLite as a more robust foundation.