It's a file in the 10-500kB and passwords are read way more often than added.
If it's even tracked as an implementation issue, it probably ranks very low and fixing this requires a lot of care not to screw up things with the safety and feature rollout.
I don't think given the file size it is all that relevant.
I mean if I wanted to start new password manager right now it would be a good choice to "just use SQLite" but for existing solution backward compatibility is far more important
> Devising a new schema based on SQLite would allow for current features that are being jerry-rigged into the attributes to have their own real place in the database
Perfectly possible with XML too
> An SQLite based store is one of the most tested and optimal formats for document and application storage
It's optimized for things that largely don't matter for password storage. The testing is admirable, but there's no issue of keepass clients crashing or corrupting data so again, not very relevant (probably because of low concurrency, simple writes etc).
> A switch this big is a major chance to fix the governance structure and align it more with a democratic consortium than a benevolent-dictator-for-life style of project management
You don't need a technical change to solve this. In fact, a fork that would fracture clients is the last thing you need when making governance changes.
> So many quality of life features can be added where the old schema disallowed it
All of the features they list can be achieved with an XML format. The format isn't what's holding them back.
I don't know if this could count as "corrupting": I made the mistake of syncing my keepassxc database to my macbook with finder webdav client (nextcloud backend) it read the file alright but when I tried to write a new secret it helpfully wrote an empty file in place, wiping nextcloud file versions in the process.
Thankfully, Nextcloud was smart enough to move the previous file in the trash bin and I could restore it.
It seems keepassxc "save" procedure here was to delete the old file and replace it with a new one and something went catastrophically wrong in the process ?
Looking at the settings there's is a parameter for this method for particular circumstances but I didn't enable it back then. Now I just have a second database only on this mac synced to icloud and never letting it near my nextcloud again.
Is kdbx broken or has it been causing data loss? I've been using KeepassXC as long as it has existed and no issues for me thus far. If kdbx is not problematic for it's intended use then I think moving to SQLite just makes it more hacker friendly which I have no need for. I have no need for other applications extending the use of my passwords.
If anything, maybe give people the option to export to SQLite and then use that going forward but keep it entirely optional.
The keepass ecosystem is comprised of a dozen implementations of the KDB(X) file spec. Some are better than others.
I built KeePass Tusk back in 2018, for example. This would kill the project and abandon 30K users without a rewrite of the JS engine (there are several now!)
I agree with you that KDBX sucks, but at this point a keepass based on SQLite would be keepass in name only, a new password manager to migrate to.
If you are serious about this proposal, one way to move forwards is to make tool that converts kdbx <-> sqlite. If you can't roundtrip that conversion perfectly then the idea is dead on arrival.
> So rather than risking sync issues uploading your 20MiB KDBX file on every minor change, you can upload just the 4KiB or so comprising that data.
Why is your KDBX file 20 MiB? It seems you are storing something that is not actually a good fit for a password manager, and expecting the entire world to change around you instead of storing those files in a more appropriate place.
Maybe it's irrational, and I cannot actually justify it (and of course safe writing is of primary importance), but somehow rewriting the whole file feels like a good thing for a secrets storage. Updating only part of a file obviously reveals something, even though it probably shouldn't matter if it doesn't reveal anything useful. But the default mode of thinking is we can never assume the leaked information cannot be used somehow.
The schema issues aren't solved by moving to sqlite, or the proposed solution is doable with XML too. I can see the same thing with the attributes (some described it as a shadow schema) happening in an attributes table just as easily. And in my experience relational schemas are a lot harder to modify than a document schema like XML.
EDIT: also you don't need to have just one password vault and I'd say you probably shouldn't, separate entries also assist with separation of concerns. This last adds a little overhead but is a reasonable workaround.
However on the whole I like sqlite for app persistence. It can, however, leak data (forensically) if not managed properly.
Some decent arguments for development concerns, but the users will certainly never notice.
For 10 years I've managed a family of 4 in a single KeePass db. Unique passwords across all accounts, random passwords instead of PII for "security questions", fake DOBs, and all other random security related stuff. Never had a single issue. Everything happens instantly as far as I can tell. And the file is 67kb.
My work dbs, separate only because they should be, are much smaller and simpler.
I love KeePass. Changing everything under the hood probably only has potential to make pain for the user. Best case is that nothing is made noticeably worse. Doesn't seem worth the risk.
A key aspect of SQLite's development model is its proprietary test suite. As far as I can tell, the SQLCipher developers do not have access to those tests.
This is not to say they aren't doing the best with what they've got, but SQLCipher is a fork of SQLite, and the scope of the changes they must make, no matter how conservatively they try to make them, should lead to a full re-test of the entire product, which they cannot do.
EDIT: I don't want this to come off as spreading FUD. The SQLCipher developers do a good job of laying out their development methodology, the relative (un-)testability of their product vs. SQLite, and other tradeoffs pretty well in the repository's README: https://github.com/sqlcipher/sqlcipher?tab=readme-ov-file#sq...
It's even weirder when people dismiss real issues as "works just great". Just use the great old version and ignore all future changes if they scare you!
> no matter how small the edit was, the entire file gets rewritten
SQLite doesn't fix this, because you would still need to encrypt the whole file (at least with standard sqlite). If you just encrypted the data in the cells of the table, then you would expose metadata in plaintext.
SQLCipher does provide that, but as mentioned by others, it isn't quite the same thing as sqlite, and is maintained by a different entity.
> The primary issue is that new features cannot be added natively to the XML tree without causing breaking changes for older clients or third-party clients which have not adopted the change yet.
That isn't a limitation of xml, and could also be an issue with sqlite. The real problem here is if clients fail if they encounter tags or attributes they don't recognize. The fix here is for clients to just ignore data it doesn't know about, whether that is xml or sqlite.
The complaints about compatibility between different implementations would be just as bad with sqlite. You would still have some implementations storing data in custom attributes, and others using builtin fields. In fact it could be even worse if separate implementations have diverging schemas for the tables.
> Governance Issues
None of this has anything to do with sqlite vs xml. It is a social issue that could be solved without switching the underlying format, or remain an issue even if it was changed.
SQLite seems like an odd dependency for a system which ultimately just journals events like "on 2026-02-24T19:36Z, entry 791 was created with username larry7 and password letmin" or "on 2026-02-24T20:51Z, the password for entry 791 became letmein2".
I think that if things are bursting at the seams this is a good idea. But we’ve added Passkeys already, and the custom metadata ship has sailed. This is the kind of initiative I could see taking off as a solution to Passkeys, but it doesn’t represent a worthwhile investment for me now.
I’m at 1.6Mb, and with the frequency by which I update entries, the cost of data migration is relatively high compared to the data cost.
> KeePass has long been the gold standard and darling of the tech world, earned through its unrelenting commitment to security, stability, and data sovereignty.
Eh? I always thought of pass[1] in that role.
> Devising a new schema based on SQLite would allow for current features that are being jerry-rigged into the attributes to have their own real place in the database, rather than clogging the user-facing fields. It also ensures that if in the future, some weird authentication method were to come out, no breaking changes would be needed. You simply would add a table to accommodate it, and old clients would simply not support the feature and just load the database without it. Of course, a warning would be shown to the user if somehow their database uses new features on an old client.
Using a relational database does not solve this problem at all. It doesn’t even address it at all.
The original problem is you have multiple implementations defining their own data model. Whether the backend is a file, a database, or a post-it note, that doesn’t work.
Just as you can ignore tables in a database, you can ignore attributes in XML.
> many users have databases that fall in the range of 10-100MiB
> use one of the many other ways to operate the database as a single file and be on your way
Don't you still have to download and upload that 100MB pretty often? I feel like password databases get modified every few days, not every few months.
Moreover, if an app really wants to optimize the file-not-modified case for people who don't modify it often, can't it just internally cache an encrypted version of the database in another format -- in SQLite, even! -- and use that when the checksum/file time/whatever matches what they expect?
I feel like a client that actually cares about the user should tell them how much more expensive the file gets with each entry being added: "Hey, based on your recent download/upload speeds on this device, embedding this 1MiB file would add a 5-second delay." Switching the entire world from XML to SQLite seems like it completely misses the fundamental issue.
My KeePass database is pretty stable at this point. I would say edits happen every few weeks, if that. My edit date is ~2 weeks ago, and it was because I was logging into an account I hadn't touched in a few years. Nothing really changes much in my personal database. I add stuff occasionally, but new accounts are few and far between, and so are password changes. I'm not sure what would be changed every few days for an individual.
Total meh from me, an end user. User of KeePass since at least 2015, I've written end-user guides, contributed to the main documentation, evangelize it to my family and friends when they have security questions.
I store every single important piece of info in my KeePass database. It stores ALL of my passwords, my SSN, credit cards, my health information, even some weird stuff like my vehicle maintainence records and whatnot. My KDBX file currently sits at 466K. Size is not a particularly compelling reason. Hate to be that guy, but if your database is much larger than that - you're probably doing it wrong.
Newer features like TOTP and passkeys are likewise not a concern for me. What did KeePassXC do when TOTP came around? They stored the relevant data in the attributes, and added a UI around it. It even works with my Steam TOTP, which is a nonstandard implementation. I haven't looked into it, but I imagine they did the same thing with passkeys. I don't see why this couldn't continue to be the paradigm they use. I don't use attributes at all - I haven't needed to, the notes section work great - but I do appreciate being able to look into the "raw data" of attributes quite easily, from within the UI.
If KeePass were being developed from scratch today, or if the developers of the various projects collectively really, really want to switch to a SQLite system of their own volition. Then sure, SQLite. I'm not going to ask them to do that now though.
---
On a separate note, an unfufilled niche that I have though, if anyone's looking for ideas. My secure password storage is a solved problem, KeePass is cross platform, easy to use, and very secure. What remains a problem is secure notes. I want to be able to write markdown (`.md`) documents, add photos and PDFs, then save it to a secure, encrypted folder somewhere. Doesn't need the same security posture as KeePass, but I don't want to leak metadata like file names.
Obsidian - my current notes app - is good from a usability standpoint, but it's not exactly secure. I could pair it up with Veracrypt, but that's a pain from a usability standpoint, and I don't trust my OS to keep the mounted Veracrypt volume contents a secret. Whatever the solution is, it must have a GPL license, or else I'm not going to trust it - from a long-term viability standpoint more than anything else.
If anyone has any suggestions here, would love to hear them.
I'd be glad if someone could enlighten me on why the whole file needs to be encrypted.
What issues does storing an encrypted value (password, metadata, etc) associated with a particular key (let's say website name) have? (apart from leaking the fact that that file has a entry associated with that site)
I'm working on an alternative to KeePass/KeepassXC called Lockstep - it is local-first password manager that supports sync natively.
It uses SQLCypher as local data store and keeps KeePass-compatible data model - supports import of .kdbx database.
SQLCypher and different schema used in Lockstep alone did not solve any problems that I have with Keepass. Those problems are sync and sharing.
Solving sync and sharing cannot be done on whole database file level, as it implemented now in KeePass. Changes need to be tracked at the password record level, all changes need to persisted as operations log and that log needs to be distributed across devices.
The above means writing a whole protocol, and that's a lot more work than changing local storage.
My problems with KeePass are rather that its development model is much like SQLite: a pretty closed model, with source published regularly, but no clear way of code contribution, which is sad because it has some UI regressions recently which I'd be happy to fix, if contribution was lower friction.
> Many file sharing tools, sync tools, and some cloud platforms (Dropbox for instance) support delta syncs with block-level delta compression.
Ok, but "some" isn't even "many", and the core reason why the single-file problem doesn't go away with sqlite
Instead the new solution must be dumb-cloud-friendly any rely on multiple files, and definitely split all the pdfs and icons away from the few kilobytes of actual user passwords
35 comments
[ 1.8 ms ] story [ 54.0 ms ] threadThis seems like an implementation issue rather than a format/spec issue.
If it's even tracked as an implementation issue, it probably ranks very low and fixing this requires a lot of care not to screw up things with the safety and feature rollout.
I mean if I wanted to start new password manager right now it would be a good choice to "just use SQLite" but for existing solution backward compatibility is far more important
I don't get it. Is this a reference to database cursors? Or is it implying that the blog post was AI generated?
Perfectly possible with XML too
> An SQLite based store is one of the most tested and optimal formats for document and application storage
It's optimized for things that largely don't matter for password storage. The testing is admirable, but there's no issue of keepass clients crashing or corrupting data so again, not very relevant (probably because of low concurrency, simple writes etc).
> A switch this big is a major chance to fix the governance structure and align it more with a democratic consortium than a benevolent-dictator-for-life style of project management
You don't need a technical change to solve this. In fact, a fork that would fracture clients is the last thing you need when making governance changes.
> So many quality of life features can be added where the old schema disallowed it
All of the features they list can be achieved with an XML format. The format isn't what's holding them back.
Not writing the entire database on every save?
If anything, maybe give people the option to export to SQLite and then use that going forward but keep it entirely optional.
I built KeePass Tusk back in 2018, for example. This would kill the project and abandon 30K users without a rewrite of the JS engine (there are several now!)
I agree with you that KDBX sucks, but at this point a keepass based on SQLite would be keepass in name only, a new password manager to migrate to.
Why is your KDBX file 20 MiB? It seems you are storing something that is not actually a good fit for a password manager, and expecting the entire world to change around you instead of storing those files in a more appropriate place.
EDIT: also you don't need to have just one password vault and I'd say you probably shouldn't, separate entries also assist with separation of concerns. This last adds a little overhead but is a reasonable workaround.
However on the whole I like sqlite for app persistence. It can, however, leak data (forensically) if not managed properly.
For 10 years I've managed a family of 4 in a single KeePass db. Unique passwords across all accounts, random passwords instead of PII for "security questions", fake DOBs, and all other random security related stuff. Never had a single issue. Everything happens instantly as far as I can tell. And the file is 67kb.
My work dbs, separate only because they should be, are much smaller and simpler.
I love KeePass. Changing everything under the hood probably only has potential to make pain for the user. Best case is that nothing is made noticeably worse. Doesn't seem worth the risk.
A key aspect of SQLite's development model is its proprietary test suite. As far as I can tell, the SQLCipher developers do not have access to those tests.
This is not to say they aren't doing the best with what they've got, but SQLCipher is a fork of SQLite, and the scope of the changes they must make, no matter how conservatively they try to make them, should lead to a full re-test of the entire product, which they cannot do.
EDIT: I don't want this to come off as spreading FUD. The SQLCipher developers do a good job of laying out their development methodology, the relative (un-)testability of their product vs. SQLite, and other tradeoffs pretty well in the repository's README: https://github.com/sqlcipher/sqlcipher?tab=readme-ov-file#sq...
It is weird when people wants to change something that works just great.
KeePass have served me well for years on Windows, Mac, Android, Linux using Dropbox and Syncthing as storage. Don't mess with it.
SQLite doesn't fix this, because you would still need to encrypt the whole file (at least with standard sqlite). If you just encrypted the data in the cells of the table, then you would expose metadata in plaintext.
SQLCipher does provide that, but as mentioned by others, it isn't quite the same thing as sqlite, and is maintained by a different entity.
> The primary issue is that new features cannot be added natively to the XML tree without causing breaking changes for older clients or third-party clients which have not adopted the change yet.
That isn't a limitation of xml, and could also be an issue with sqlite. The real problem here is if clients fail if they encounter tags or attributes they don't recognize. The fix here is for clients to just ignore data it doesn't know about, whether that is xml or sqlite.
The complaints about compatibility between different implementations would be just as bad with sqlite. You would still have some implementations storing data in custom attributes, and others using builtin fields. In fact it could be even worse if separate implementations have diverging schemas for the tables.
> Governance Issues
None of this has anything to do with sqlite vs xml. It is a social issue that could be solved without switching the underlying format, or remain an issue even if it was changed.
I’m at 1.6Mb, and with the frequency by which I update entries, the cost of data migration is relatively high compared to the data cost.
Eh? I always thought of pass[1] in that role.
> Devising a new schema based on SQLite would allow for current features that are being jerry-rigged into the attributes to have their own real place in the database, rather than clogging the user-facing fields. It also ensures that if in the future, some weird authentication method were to come out, no breaking changes would be needed. You simply would add a table to accommodate it, and old clients would simply not support the feature and just load the database without it. Of course, a warning would be shown to the user if somehow their database uses new features on an old client.
Using a relational database does not solve this problem at all. It doesn’t even address it at all.
The original problem is you have multiple implementations defining their own data model. Whether the backend is a file, a database, or a post-it note, that doesn’t work.
Just as you can ignore tables in a database, you can ignore attributes in XML.
[1]: https://www.passwordstore.org/
> use one of the many other ways to operate the database as a single file and be on your way
Don't you still have to download and upload that 100MB pretty often? I feel like password databases get modified every few days, not every few months.
Moreover, if an app really wants to optimize the file-not-modified case for people who don't modify it often, can't it just internally cache an encrypted version of the database in another format -- in SQLite, even! -- and use that when the checksum/file time/whatever matches what they expect?
I feel like a client that actually cares about the user should tell them how much more expensive the file gets with each entry being added: "Hey, based on your recent download/upload speeds on this device, embedding this 1MiB file would add a 5-second delay." Switching the entire world from XML to SQLite seems like it completely misses the fundamental issue.
I store every single important piece of info in my KeePass database. It stores ALL of my passwords, my SSN, credit cards, my health information, even some weird stuff like my vehicle maintainence records and whatnot. My KDBX file currently sits at 466K. Size is not a particularly compelling reason. Hate to be that guy, but if your database is much larger than that - you're probably doing it wrong.
Newer features like TOTP and passkeys are likewise not a concern for me. What did KeePassXC do when TOTP came around? They stored the relevant data in the attributes, and added a UI around it. It even works with my Steam TOTP, which is a nonstandard implementation. I haven't looked into it, but I imagine they did the same thing with passkeys. I don't see why this couldn't continue to be the paradigm they use. I don't use attributes at all - I haven't needed to, the notes section work great - but I do appreciate being able to look into the "raw data" of attributes quite easily, from within the UI.
If KeePass were being developed from scratch today, or if the developers of the various projects collectively really, really want to switch to a SQLite system of their own volition. Then sure, SQLite. I'm not going to ask them to do that now though.
---
On a separate note, an unfufilled niche that I have though, if anyone's looking for ideas. My secure password storage is a solved problem, KeePass is cross platform, easy to use, and very secure. What remains a problem is secure notes. I want to be able to write markdown (`.md`) documents, add photos and PDFs, then save it to a secure, encrypted folder somewhere. Doesn't need the same security posture as KeePass, but I don't want to leak metadata like file names.
Obsidian - my current notes app - is good from a usability standpoint, but it's not exactly secure. I could pair it up with Veracrypt, but that's a pain from a usability standpoint, and I don't trust my OS to keep the mounted Veracrypt volume contents a secret. Whatever the solution is, it must have a GPL license, or else I'm not going to trust it - from a long-term viability standpoint more than anything else.
If anyone has any suggestions here, would love to hear them.
You can pay me to build you SAP in Excel, but you really shouldn't!
If you have a 100mb password database, should you be moving to a more scalable solution?
What issues does storing an encrypted value (password, metadata, etc) associated with a particular key (let's say website name) have? (apart from leaking the fact that that file has a entry associated with that site)
It uses SQLCypher as local data store and keeps KeePass-compatible data model - supports import of .kdbx database.
SQLCypher and different schema used in Lockstep alone did not solve any problems that I have with Keepass. Those problems are sync and sharing.
Solving sync and sharing cannot be done on whole database file level, as it implemented now in KeePass. Changes need to be tracked at the password record level, all changes need to persisted as operations log and that log needs to be distributed across devices.
The above means writing a whole protocol, and that's a lot more work than changing local storage.
The project is pre-alfa https://github.com/lockstepvault-hq/lockstep
Ok, but "some" isn't even "many", and the core reason why the single-file problem doesn't go away with sqlite
Instead the new solution must be dumb-cloud-friendly any rely on multiple files, and definitely split all the pdfs and icons away from the few kilobytes of actual user passwords