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!
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.
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.
> 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!
Smaller ideas that would address this: add support for non-CBC encryption modes, tweak/disable the compression so that small changes require less rewriting.
I see, thanks. Have you considered moving to Bitwarden?
Not encrypting everything as a whole however leaks information about the structure and what/how much was changed between two versions of the file.