3 ms·
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 si
by appplication 5mo ago
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 5mo agoIIRC SQLite is in-process and says in it's documentation that it is not a client-server database.
- setr 5mo agoIt’s not, but you could do something like https://litestream.io/ https://litestream.io/ and just continuously replicate it to pretend to be multi-user
- hermitcrab 5mo agoDoes SQLite + replication have any advantages over client-server, for someone not already using SQLite?
- setr 5mo agoTrivial 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 5mo agoThat is helpful, thank you.