151 points by wps 5 days ago | 114 comments on HN
| Moderate positive
Contested
Editorial · v3.7· 2026-02-26 04:33:20 0
Summary Data Sovereignty & Democratic Governance Advocates
This technical blog post advocates for reforming the KeePass password manager format from XML (KDBX) to SQLite-based storage, framing the argument around user autonomy, data sovereignty, and democratic governance. The content champions free access to information, open technical standards, and collaborative decision-making over unilateral control, while addressing practical privacy and security concerns.
> 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.
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.
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...
> 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.
> 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.
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.
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!
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 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.
"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."
My kdbx is only 173 KB, but I don't hate this idea.
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 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.
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.
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.
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.
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).
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.
KDBX seems unique in this threat model out of the major providers. The cloud ones all use a relational DB, while major local ones like Enpass & Codebook just use a SQLCipher store. I wish someone with some real experience here would chime in: What metadata does a SQLCipher DB leak that a KDBX file does not? I mention that both of them obviously reveal the size of your vault to an attacker (w/ KDBX reporting the size more accurately, ultimately irrelevant), which is pragmatically unavoidable information leakage.
> The migration process would also be frictionless for users, it is a simple data map between probably the two easiest formats of all time.
I cannot imagine how you could mess this up. The developers already implement numerous export formats. The migration is the easiest part. The actual implementation of a new data format into the codebase and all the new security and robustness testing is the difficult part.
I think a relational DB is the best tool for the job!
I argue more for the use case of "secrets manager" than solely password manager. People store TOTP seeds and Passkeys and a myriad attachments. A SQLite store would better facilitate this, as not everything has to be in memory all the time. This is only with regard to the size constraint, there are so many other benefits to be had from a formal specification of the schema to truly future-proof the standard.
I'm not sure why it's a concern that the whole file needs a rewrite.
Naiively perhaps I thought that was helpful with solid state storage because it means that old data is trimmed faster?
It mentions it near the entire file being in memory but that seems a dubious concern. If the key is in memory the entire file can be comprised either way. Nothing can really stop that if you have access to the programs memory.
Breaking format changes is not such a major issue, they happened before: kdb → pre-2.08 kdbx → kdbx3 → kdbx4. If the new format is worth it, popular apps will adopt it within a few years — while still supporting older formats. Users would just stick with their current format until the ecosystem catches up, as it happened with KDBX and KDBX4.
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.
Content advocates for open information standards, democratic governance of technical specs, and freedom from centralized control of communication infrastructure. Critiques proprietary decisions and advocates for collaborative, transparent standard-setting.
FW Ratio: 57%
Observable Facts
Article explicitly calls for 'a modern, open democratic spec' rather than 'benevolent-dictator-for-life style of project management'.
Content is publicly accessible without paywall or registration barriers.
Author actively engages in comment section discourse, responding to technical questions and critiques.
Article advocates that 'the majority of users within the KeePass ecosystem' should have voice in format decisions, not unilateral control.
Inferences
Advocacy for democratic governance of technical standards reflects commitment to free expression and participation in decisions affecting users.
Open publication and engagement model demonstrates structural commitment to free speech and transparent discourse.
Critique of centralized decision-making aligns with freedom of information principles.
Content advocates for protection against arbitrary interference with privacy through improved data format design and governance that prevents unauthorized access to sensitive personal information.
FW Ratio: 50%
Observable Facts
Article discusses problems with metadata leakage from file formats and advocates for SQLCipher encryption to protect against forensic analysis.
Discussion emphasizes user control and freedom from arbitrary server-level interference through local-first architecture rather than cloud-based centralization.
Inferences
The advocacy for SQLCipher and local-first storage reflects concern for protecting privacy from both institutional and technical interference.
Emphasis on democratic governance of the file format spec suggests alignment with preventing arbitrary control over personal data.
Content advocates for protection of personal data and ownership through improved technical architecture that gives users control over their secrets management.
FW Ratio: 67%
Observable Facts
Article emphasizes 'data sovereignty' as core value of KeePass and advocates for local-first design giving users control over their password databases.
Discussion frames user ownership of data as central problem: 'you cannot just update every user's file at once' in local-first systems, requiring user consent.
Inferences
The emphasis on data sovereignty and user control reflects underlying concern for property rights and ownership of personal information.
Content advocates for collective action and democratic participation in technical governance: 'voice your support in the relevant public development forums and channels.' Frames users as collective stakeholders with rights to participation.
FW Ratio: 67%
Observable Facts
Article includes explicit call to action: 'As for users, if the arguments persuaded you, voice your support in the relevant public development forums and channels.'
Discussion frames KeePass ecosystem as collective enterprise where multiple developers and users should have joint say in format decisions.
Inferences
The call for democratic participation reflects commitment to freedom of assembly and collective decision-making.
Content frames data sovereignty and security as foundational values of KeePass, aligning with preamble principles of human dignity and freedom from arbitrary interference.
FW Ratio: 67%
Observable Facts
Article explicitly states: 'KeePass has long been the gold standard and darling of the tech world, earned through its unrelenting commitment to security, stability, and data sovereignty.'
Discussion of file format governance emphasizes user freedom and control over personal data.
Inferences
The emphasis on data sovereignty suggests underlying concern for individual autonomy and protection from external control.
Content implicitly engages with duties to community by framing technical governance as responsibility to broader KeePass ecosystem of users and developers.
FW Ratio: 50%
Observable Facts
Article frames the governance problem as issue affecting 'vast majority of users within the KeePass ecosystem' and calls for collaborative spec development 'from start to finish'.
Inferences
The emphasis on collective responsibility and shared governance suggests underlying conception of duties to community.
Content is published openly without paywall or registration requirements, supporting free access to information and technical knowledge. Public commentary section demonstrates practice of open discourse.
build 1ad9551+j7zs · deployed 2026-03-02 09:09 UTC · evaluated 2026-03-02 10:41:39 UTC
Support HN HRCB
Each evaluation uses real API credits. HN HRCB runs on donations — no ads, no paywalls.
If you find it useful, please consider helping keep it running.