[galaxyLogic]

How about: Have 1 + N separate SQLite database-files.

Each user would have their own database-file which contains only information about that user. Then 1 shared database-file which contains info needed for all users.

Users would update their own data, which is a small database file which can be easily uploaded. They would not need to update the shared data.

Not knowing your app I don't know what the shared data would contain, presumably something. Perhaps the shared data-file would be updated on the server based on what individual user-data the users upload.

[anovick]

In this multi-tenant arrangement, you run into synchronization problems.

Developers should expect users to connect to the service using multiple devices (clients).

AFAIK bare SQLite doesn't offer synchronization mechanisms between multiple SQLite instances.

I believe Turso offers some solution of this kind, but not sure if that's open source or not.

[galaxyLogic]

> expect users to connect to the service using multiple devices (clients).

But probably using only one device at a time by a single user?

My thought, and it is just a thought, here is that instead of trying to provide a GENERAL solution for all kinds of data-update patterns, it is often possible to think in terms of what my current application specifically needs. It is easier to come up with such a solution with SQLite per app because SQLite is so "lite".

I can't speak for the "general solution" except to say that many times you don't need an all-encompassing general solution, just a solution for your current app.

[normie3000]

> But probably using only one device at a time by a single user?

It depends on your expectations of concurrent use. Computer + tablet + phone means many users may use different devices within seconds of each other. If you want to support offline-first usage, concurrent updates from different clients for the same user becomes more likely.