News for hackers. Stuff that matters.
Re:Learning a few things about running SQLite by gabeio on Friday July 17, 2026 @04:35PM (#48952008)
> However, it's only meant for local systems. Once you need to connect over a network or robustly handle simultaneous requests

That’s not really accurate any longer.

Mostly depends on how you layout your tables & files. If you shard the databases then multiple machines can act as writers for their shard. You can also split read requests from write requests and have read only machines scale up/down as much as you’d like. You can use multiple files in a query (there is a limit there).

So for example you can split the user table based on the first letter of the username and then depending on the rest of the database either a database file per user or per customer (organization). Of course more of everything is manual but it’s not as hard as you’d expect if you build for it.

https://rivet.dev/blog/2025-02-16-sqlite-on-the-server-is-mi...

If you need sqlite over the network you can look at https://turso.tech/ it’s a almost drop in replacement for sqlite (https://github.com/tursodatabase/turso/blob/main/COMPAT.md)

Re:Learning a few things about running SQLite by inigyou on Friday July 17, 2026 @07:31PM (#48953445)
At this point you're building your own networked database using sqlite just as a backing store. You should really reconsider if it's easier than using something designed for it.

If your entire system is sharded by username anyway for other reasons, then maybe what you've described works for you.

Re:Learning a few things about running SQLite by Kalanos on Saturday July 18, 2026 @08:30PM (#48963839)
sharding locally defeats the purpose of sharding; splitting it up across machines to get more resources