[thayne]

> 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.

[ktimespi]

SQLite has its own closed-source page-level cipher format, so I don't think this argument makes sense.

https://www.sqlite.org/see/doc/trunk/www/readme.wiki

A weakness though, again, is that this is closed source...

[wps]

The biggest weakness is the cost. Each client would have to purchase an expensive license. The source code is provided upon purchase though, but essentially destroys the ability to build a client from source due to the compiled binary distribution.

[thayne]

That isn't really an option for an open source project like keepass(xc)

[rustyhancock]

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.

[thayne]

It's an issue if you have a really big password database, for example because you are storing large attachments in there. Especially if you are also syncing the file over the network. Also if your file is multiple GB, having it all in memory is an issue because of the amount of memory used.

That isn't really how keepass is meant to be used, but apparently people do use it this way.