alt Hacker NewsI 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.
Replies
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 should 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.
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.
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 worse and plan 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.
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.
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. Something everyone should be doing regardless.