Re:Why the KeePass format should be based on SQLite
by KeePassium on Wednesday February 25, 2026 @04:06PM
(#47157860)
As for autofill memory limitations, this is largely an implementation detail: just process data stream in small chunks, that's it.
Unfortunately, KeePassium's data layer was designed in the times of iOS 11, before AutoFill became a thing. So I chose the easier path of loading and processing the whole file at once. This made sense for 10-20 MB databases on iPhones with 2 GB of RAM. By the time the mistake became obvious, it was much harder to switch to streamed processing, especially with a long queue of lower-hanging feature requests.
Re:Why the KeePass format should be based on SQLite
by wps on Wednesday February 25, 2026 @04:33PM
(#47158204)
This class of mistake could have been wholly avoided if the format was SQLite based because there is no assumption that everything must be loaded into memory. Of course I defer expertise to you, but I've had a far better time with SQLite than I've ever had with XML parsing (OFX/QBO still bother me...)
Re:Why the KeePass format should be based on SQLite
by wps on Wednesday February 25, 2026 @04:29PM
(#47158149)
I really appreciate your commentary here! I understand that SQLite would not automatically solve the politics issue. As ctoth mentioned, it would serve as a "flag day" for the KeePass community to hopefully cover everyone's bases in a formal manner. Schema versioning and evolution is way more up SQLite's alley. An SQLite schema has referential integrity which an XML schema lacks, making it harder to misuse and contort. It is also far simpler to modify a query in the event passkey storage need to be changed than it is to modify the parser.
The lower barrier to entry probably also reduces the number of catastrophic parsing mistakes a developer can make. This is a net positive gain for the wider ecosystem of external tools which do not have to re-implement the whole parser. Every language has a great SQLite library, the same cannot be said of KDBX.
That said, most of the concerns raised by the article — outdated schema, inefficiencies, governance issues — call for a new iteration of database format, but not necessarily SQLite. However, we would still be debating how to represent entry templates and how to accommodate features that stretch format's initial assumptions (be it multi-URLs or smart groups). We may still discover that passkeys need more fields than initially foreseen. Then someone would come up with item-level access rights scheme. Then something else.
All of these are already possible with XML+Gzip, just as much as with SQLite/SQLCipher. The main advantage of the latter is the standard, multi-platform library with a permissive license, instead of KDBX' specialized parsing. Switching to SQLite would probably lower the entry barrier for new apps. Which would be a good thing on the surface (more choice), but could end up with the same devil-in-details bedlam as the status quo.