That is true, but in my experience this is less of an issue if your migration allow running against "current - 1". If your migration borks on one of the tenants - your system should still work, and you can grab that tenant and investigate.

This problem also does happen with sharded databases - which is why most co's have a structured approach of deploying schema changes, observing them having applied everywhere, and only then deploying the feature relying on the schema changes.

Yeah but “schemas out of sync!” Is a never ending development and operations problem with SQLite database per tenant.

Postgres row level access control gives all the benefits of strong isolation with none of the pain of schemas getting out of sync.

You do need to keep tabs on whether they are or not, that is true - and you will have a bit of management to do if they are under constant heavy write load. For me, this all works out because I don't have too many tenants - and I have tools to block writes when running migrations.

It's all tradeoffs after all.

I’d heard of using Postgres schemas before but not RLS. Interesting…

https://www.crunchydata.com/blog/row-level-security-for-tena...

Shouldn't the service daemon upgrade schema and perform migrations on initialisation?

Before performing upgrade make a copy of the db file. Also multiple DBs can be inited in parallel.

I fail to see why this might be so hard.