Given the catastrophic outcomes associated with corruption of the DB, I can’t imagine trusting the keepassxc approach.
How can they possibly handle concurrent updates to the password database correctly across that range of cloud filesystem products? Each has different semantics. Does someone fuzz test the whole stack, at least? For which services?
First and foremost, automate backing up your database. NextCloud also supports versioned files, so if something does go wrong, you can roll-back to a working DB as a last resort.
A good syncing application will not upload files that are currently opened in write mode. This way you cannot upload files mid-write, preventing uploading corrupted DBs. This of course assumes that both KeePassXC and NextCloud are perfect, but even if something breaks there you have your automated backups and previous versions of the database file. I should note that this has never happened to me, but if it were to happen I am safe.
In case you have diverging databases (e.g. server is offline and you add a new account on device 1 and a different account on device 2), NextCloud will create a conflict file which you can merge from the KeePassXC client to resolve the issue. No accounts are lost but it is an additional manual step to get all your changes back into the "main" DB.
I do wonder about attack surface / operational complexity though. It syncs to three clouds and there is a postgres database, apparently.
Operating that myself reliably seems hard. I’m not looking for a hobby project and LastPass is the Last cloud hosted e2ee Password manager I will ever trust.
Any suggestions for something I can host at home? It needs mac, linux and ios clients and (unlike bitwarden) must gracefully handle the server being unavailable.