> no matter how small the edit was, the entire file gets rewritten<p>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.<p>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.<p>> 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.<p>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.<p>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.<p>> Governance Issues<p>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.
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.<p>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.<p>However on the whole I like sqlite for app persistence. It can, however, leak data (forensically) if not managed properly.
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.<p>If anything, maybe give people the option to export to SQLite and then use that going forward but keep it entirely optional.
Exporting to a relational db is beside the point. You can very easily just export a CSV file and double click it in DB Browser and have something working. Or you could export the XML document and write a quick importer for it. But genuinely what benefit does it provide other than allowing me to hack at my unencrypted db with sql statements? All the benefits that I was referring to are for daily usage of a KeePass client, not for a one off export.
I don't want to assume you didn't read the article, but this isn't really about the database engine. It's about the shadow schema that has grown up around the format. The database switch would serve as a flag day to unify things. It won't be a permanent fix, nothing at this scale ever is, and we'll probably need another migration in a few decades. Still worth doing.
I think that's where I see the most concerns with this proposal: XML is already an extensible format (that's what the X stands for) and XML schema changes <i>should</i> be simpler than needing to run SQL migrations (alter/drop/etc). A switch to SQL doesn't guarantee that schema extensions better align as standards or allow for easier schema modifications. I think it more extends the risk that schema components get ossified and harder to extend.<p>That problem that the current schema doesn't have enough ways to declare custom memory-protected fields outside of user-facing attributes seems just as likely to be replicated and maybe worsened in an SQL schema.<p>Changing the database engine doesn't fix the architecture problems nor schema migration problems. It's certainly a good time to reevaluate the architecture problems and the schema migration problems. But the huge caution I'd suggest here would be look at the ossification complaints about the current XML schema and expect SQL migrations to be <i>worse</i> and <i>plan</i> for worse multi-schema operations and intenser ossification. (Especially because these files are expected to live in a large multi-vendor ecosystem, SQLite schema migration management is going to be much worse than any XML schema management.)
I read it and I get it but I have never run into problems with KP using its existing schema. The only reason I could see this debate making sense would be if third parties want to integrate with it otherwise it works perfectly fine. And sure if it's worth doing then make it optional like I said. Have an export as SQLite, MySQL, Postgres, Oracle, DB2 but keep it optional given there is no need otherwise. This is solving a perceived problem that does not exist or creating a problem where there isn't one.<p>As for scale this app is for one person doing one query at a time or saving one password at a time. One person will not be saving millions of passwords or if for some reason they are then they can export to a format that an enterprise solution could take it's place. People have written team / company password managers that can use Oracle, MySQL and Postgres that can track and audit user and team password changes. This is not something that should ever be expected of an individual personal password manager like KeepassXC.<p>This is just my take but I would rather have the maintainers of KP focus on bugs, usability issues, quality of life enhancements which they have been doing great thus far in my opinion. Forcing a schema migration is just asking for trouble and potentially causing bugs that turn some people away from using it or cause people to lose data if they do not have snapshots of their database. Or if forcing a schema change make for damn sure there are many backups in each format and encourage the users to back up all the files to many external encrypted drives and store some of the encrypted devices off-site. <i>Something everyone should be doing regardless.</i>
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".
This is a reductionist take on what password managers actually need to do. A journal log is actually worse than the XML in this regard in that the number of events far exceeds the actual relevant relations. Also, adding an attachment/icon his no longer possible. Simple group associations and tags also become a complex nightmare in a log based system, whereas in SQLite they are super easy relationships. Relating passkeys, totp strings, icons, extensive history, etc all to one entry becomes too much of a task for that kind of format to handle.
> 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.<p>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.
We have a single kdbx with nearly 7000 entries. It is about 45MB at the moment with very few text docs in it. It once got to over 100MB when I found people using it as a doc store but it had a bit of a clear out a few years back.
"The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man."<p>My kdbx is only 173 KB, but I don't hate this idea.
I don't use KP, but I have a pdf for my floor safe in my password manager. I only open it a few times per year and I need more than just the combination, I need instructions on whether the first number is cw or ccw. While I could no doubt look it up on the internet every time, I was fearful that the user's manual might some day disappear from the internet. Some things that aren't obviously passwords still belong in a password manager.
In my mental model, the PDF is not a secret and can be stored anywhere -- encrypted, if desired, but it sounds like a public document.<p>The safe combination is a secret, and obviously belongs in secret storage.<p>In this specific example, if I had trouble remembering whether the first number of the combination was reached via cw or ccw rotations, I'd include that in the secret, e.g. "cw34-12-22-45".<p>(Some safe combinations require multiple rotations. I unintentionally became the owner of one that is something like "cw3x34-ccw2x12-cw5x22-ccw2x45". I still can't open it actually, but that pattern is what the Internet tells me. :)
Were that me (I used KP), it would be in a different kdbx file. This is one of the benefits of KP, I have about 8 different vaults for various things. I don't like putting my eggs in one basket.
> 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<p>Perfectly possible with XML too<p>> An SQLite based store is one of the most tested and optimal formats for document and application storage<p>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).<p>> 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<p>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.<p>> So many quality of life features can be added where the old schema disallowed it<p>All of the features they list can be achieved with an XML format. The format isn't what's holding them back.
> All of the features they list can be achieved with an XML format.<p>Not writing the entire database on every save?
Not a problem for XML per se (you can work with byte positions, and with fixed-size blocks to avoid resizing/relocation), but in the case of KDBX there is the issue that it is encrypted as a whole. Not encrypting as a whole, on the other hand, risks leaking more information about the contents, like you can see which parts/how much changed between one update and the next.
Whole-file encryption with authentication is also more tamper-resistant. Basically the only thing an adversary can get away with there is rolling back the entire file to a previous version.<p>Whereas, any incrementally encrypted format has the additional risk of piecewise manipulations. For example, while SQLCipher authenticates each page, it doesn't authenticate the entire file, allowing for pages to be deleted, reordered, or duplicated (though duplication is easy to detect since each page has its own IV). The end result will generally just be a corrupted database, which will probably get detected by PRAGMA integrity_check, but compared to KDBX, this will not be detected by default nor is it guaranteed to be detectable at all.
That's not a feature, that's an implementation detail.
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.
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 <i>something</i>, even though it probably shouldn't matter if it doesn't reveal anything <i>useful</i>. But the default mode of thinking is we can never assume the leaked information cannot be used somehow.
I do use it, and rewriting the whole file annoys me especially when the storage is not local and the database contains sizable blobs. For storing passwords and short secrets, it makes little to no difference but if I have 10 1MB blobs stored in there, it becomes upsetting.
Well, yes, this is what OP is saying, and I'm not arguing against that. However, this is not what *.kdbx was designed for. And I am only talking about what cryptographically changes for the intended use case if we encrypt every page separately.
Just create a new password manager using SQLCipher then?
If it is good enough people will use it.<p>It is weird when people wants to change something that works just great.<p>KeePass have served me well for years on Windows, Mac, Android, Linux using Dropbox and Syncthing as storage. Don't mess with it.
The keepass ecosystem is comprised of a dozen implementations of the KDB(X) file spec. Some are better than others.<p>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!)<p>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.
Hey I’ve seen your project before! You bring up a super good point that I was thinking of when I brought up the idea that the extension should be renamed to .kp . Really the only reason to keep the KeePass name would be branding, people know and trust it. Honestly my dream password manager is essentially something that uses the CodeBook (by SQLCipher authors) storage format, but with the nice trustworthy, FOSS KeePass ecosystem chrome on top of it (keepassxc<-browser>, keepassium, etc).
SQLCipher is not SQLite.<p>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.<p>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.<p>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: <a href="https://github.com/sqlcipher/sqlcipher?tab=readme-ov-file#sqlcipher" rel="nofollow">https://github.com/sqlcipher/sqlcipher?tab=readme-ov-file#sq...</a>
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.
> <i>My cursory (lol, get it?) understanding may be incorrect.</i><p>I don't get it. Is this a reference to database cursors? Or is it implying that the blog post was AI generated?
Just checking the size of my .kdbx file: under 100K.
Some decent arguments for development concerns, but the users will certainly never notice.<p>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.<p>My work dbs, separate only because they should be, are much smaller and simpler.<p>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.
>Important to note is that every time a KDBX file is updated, no matter how small the edit was, the entire file gets rewritten.<p>This seems like an implementation issue rather than a format/spec issue.
Because KDBX is a gzipped and encrypted stream, this is actually fundamentally an issue with the spec itself. A client must re-encrypt and compress the file prior to writing because a mere append operation is not possible. SQLite solves this issue by allowing you to write with page level granularity rather than being forced to dump the whole file for a single tiny change!
Not encrypting everything as a whole however leaks information about the structure and what/how much was changed between two versions of the file.
> SQLite solves this issue by allowing you to write with page level granularity rather than being forced to dump the whole file for a single tiny change!<p>Smaller ideas that would address this: add support for non-CBC encryption modes, tweak/disable the compression so that small changes require less rewriting.
Couldn't they simply switch to zip files? Those have an index and allow opening individual files within the archive without reading the whole thing.<p>Also, I don't understand how using XML makes for a brittle schema and how SQL would solve it. If clients choke on unexpected XML elements, they could also do a "SELECT *" in SQL and choke on unexpected columns. And the problem with people adding different attributes seems like just the thing XML namespaces was designed for.
It's a single XML file. Zip sounds like the worst of both worlds. You would need a new schema that had individual files at some level (probably at the "row level.") The article mentions SQLCipher which allows encrypting individual values separately with different keys. Using different keys for different parts of a kdbx sounds ridiculous, but I could totally imagine each row being encrypted with a compound key - a database-level key and a row-level key, or using PKI with a hardware token so that you don't need to decrypt the whole row to read a single field, and a passive observer with access to the machine's memory can't gain access to secrets the user didn't explicitly request.
A ZIP file with solid encryption (i.e., the archive is encrypted as a single whole) has all of the same tradeoffs as a KDBX file as far as incremental updates are concerned.<p>A ZIP file with incremental encryption (i.e., each file is individually encrypted as a separate item) has its own problems. Notably: the file names are exposed (though this can be mitigated), the file metadata is not authenticated, and <i>the central directory is not authenticated</i>. So sure, you can read that index, but you can't trust it, so what good is it doing? Also, to support incremental updates, you'd either have to keep all the old versions of a file around, or else remove them and end up rewriting most/all of the archive anyway. It's frankly just not a very good format.
I see, thanks. Have you considered moving to Bitwarden?
Yes actually, I have personally onboarded several people to BitWarden! (Including manually migrating their accounts, setting passwords and passkeys, etc) However, I dislike the centralization and lack of control. There was a paper discussed within the past couple days on HN about what a malicious BitWarden server was capable of, despite BitWarden's marketing. I believe BitWarden's team responded promptly and appropriately to the research.<p>VaultWarden is a good compromise (offers the choice of SQLite or Postgres under the hood), putting you in charge of the primary server, but it is honestly overkill for a single personal user compared to a kdbx file on a webdav share.
It's a file in the 10-500kB and passwords are read way more often than added.<p>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.
That's probably a security feature.
i would say it’s the correct implementation as you can’t edit atomically. write and move is what you have to do
It's not an issue, write-new-and-swap is probably the best approach for this type of application.
You need format supporting append/edit first before you can implement it "right"
I don't think given the file size it is all that relevant.<p>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