Stephen Margheim - How (and why) to run SQLite in production

[@denissorn]

500 requests per second is ridiculously low for SQLite. I'm assuming this is b/c of RoR? Would it work faster simply b/c of a different DBMS?

[@MattCCrampton]

I guess I’m missing something fundamental after listening to this talk, I have two servers that talk to the same database. As far as I can tell using SQLite in prod does not scale past a single server. Is there something here I didn’t understand?

[@Dominik-K]

That is true in itself, though offerings like Turso /LibSQL make it possible to have changes be synchronized between a central server and your web servers. Before Turso, I've deployed some applications that just redirected write traffic to a master server and used tools, like Litestream, to update the read replicas automatically. Using Sqlite with multiple databases and database files, one person tenant, made it possible to still distribute writes, since each server was the master of a few of those tenants. With tools like Turso the effort to implement such solutions goes down dramatically though

[@TheRealCornPop]

And now your vendor locked in to Turso when you could have just used Postgresql

[@vivekseth3210]

You are correct. If you use SQLite, you cannot have 2 servers talk to the same database. The vast majority of applications will work just fine with 1 server, and can use vertical scaling to avoid performance issues. If your use-case absolutely needs >1 server, than sqlite might not be the right fit for you.

[@hbobenicio]

I got curious on the reasoning about disabling THREADSAFE and using ALLOCA (dynamic stack allocation, which is generally a bad idea. that's why linux avoid VLA's, which are just really bad). What about we're on a multithreaded environment and what happens to sqlite it alloca fails?