Why the KeePass format should be based on SQLite

Original Article ↗ Hacker News Discussion ↗

File rewrites, performance, and attachments

  • Core complaint: KDBX is a compressed, fully encrypted stream, so any change requires rewriting and re-encrypting the whole file; SQLite/SQLCipher would allow page-level updates.
  • Others argue most vaults are tiny (tens–hundreds of KB), so rewrite cost is negligible and not worth a disruptive format change.
  • Pain appears mainly for large vaults (tens of MB or more) or when syncing over slow/remote storage, especially with big binary attachments.
  • Some propose smaller changes (different encryption modes, tweaking compression) instead of a full switch to SQLite.

Security tradeoffs: whole-file vs page-level encryption

  • Whole-file authenticated encryption is seen as robust and simple: only full rollback attacks are possible, no per-chunk tampering.
  • Page/block-level encryption (SQLCipher, ZIP-like schemes) enables incremental writes but may leak which parts changed and allow localized manipulation unless carefully authenticated.
  • Several commenters explicitly like that KDBX rewrites everything; any partial-update format is viewed as information leakage about structure and change patterns.

Schema, extensibility, and governance

  • The article’s “shadow schema” critique (overuse of attributes for new features like TOTP/passkeys) resonates with some, but many argue XML is already extensible and the real problem is clients that fail on unknown elements.
  • Skeptics say every feature cited (templates, multi-URL, new auth methods) can be done in XML; switching to SQLite doesn’t automatically fix coordination or governance.
  • Others see a schema redesign plus SQLite as a “flag day” opportunity to clean up the spec, add referential integrity, and lower the barrier for new implementations via standard libraries instead of custom KDBX parsers.

User experience, risk, and backward compatibility

  • Many long-time users report years of trouble-free use and very small databases; for them, benefits of SQLite are purely theoretical and the migration risk feels unjustified.
  • Preference from this group: keep KDBX, maybe add optional export/alternative backends, and focus developer effort on UX and features.
  • Others note past breaking changes (kdb → kdbx → kdbx3/4) were survivable, suggesting a new format could coexist until adoption catches up.

Sync, sharing, and ecosystem impact

  • Some sync-related data loss stories are attributed more to flaky WebDAV/Cloud clients than to KDBX itself, though whole-file saves exacerbate the impact of such bugs.
  • Commenters working on alternatives point out that real solutions for sync/sharing require record-level change logs and protocols; just swapping XML for SQLite doesn’t solve that.
  • There is concern that a non-KDBX format would effectively create a new password manager and strand existing clients (browser extensions, mobile apps), though others argue the ecosystem has weathered format changes before.