[appplication]

DuckDB is more for analytics. I don’t think you’re going to find good options for a DB that can handle concurrent users without hosting it in some way server side. It’s certainly possible (think how some games create their own client servers for direct multiplayer) but honestly hosting Postgres or SQLite is ridiculously cheap, easy, and more importantly the standard approach to this issue.

[hermitcrab]

IIRC SQLite is in-process and says in it's documentation that it is not a client-server database.

[setr]

It’s not, but you could do something like https://litestream.io/ and just continuously replicate it to pretend to be multi-user

[hermitcrab]

Does SQLite + replication have any advantages over client-server, for someone not already using SQLite?

[setr]

Trivial deployment model, can avoid owning/managing your own server, easier coding in the sense that no-network means you can do normally-psychotic things like N+1 queries and single-row inserts and get away with it.

SQLite/DuckDB actually enables a bunch of normally-illegal behavior when you compare to normal databases. Backups is just copy&paste of a file; spamming queries willy-nilly becomes cheap; you can version the whole DB in git (can’t diff it properly.. but you can do cross-db queries with SQLite ATTACH); locking concerns goes out the window because it’s single-writer anyways.

But if I were actively trying to support multiple users with a single source of truth, I’d probably default to Postgres. If it’s single-user, default to SQLite/DuckDB. If it’s single-user with multiple devices, default to SQLite + replication.

[hermitcrab]

That is helpful, thank you.