Author here: these are my original speaker notes and slides stitched together for the talk that I gave at Rails World 2024 in Toronto at the end of September. There is a link to the YouTube video at the top of the post. Unfortunately, the video doesn't display my slides as much as I was hoping, so I wanted to publish this post so that people can get the full message, as the slides are an important facet of the message.
Reading the title makes me think that I’m about to see an article about Pocketbase [0]. With the big refactoring in RC (v0.23.0), extending Pocketbase is going to be much better.
I only scrolled through this, and didn’t see an answer, but in this case more than one process can’t access the DB right? And presumably you’ve lost the ability to connect to the DB and poke around in the data?
Rails works with a connection pool and multiple threads processing incoming requests. Not a problem. In fact, Rails has one of the very best tunings to use SQLite in production in the context of a web application. And yes, you can also start a console session in production while your app is running. Just maybe don't make a long-running write query from within that console ;)
SQLite works fine with more than one process accessing the database, provided those processes are on the same machine and not attempting to coordinate over something like NFS.
You can connect to an in-use SQLite database using other tools (like the sqlite3 CLI tool or my https://datasette.io local web app) just fine.
The only thing to avoid is long running write operations, since those will block writes from other processes for their duration.
Enabling WAL mode avoids errors if you try to read while some other process is performing a write.
You can test this yourself: fire up a few terminal terminal windows and run sqlite3 multiple times against the same file on disk and see what happens.
Wal mode allows for concurrent readers and one writer. I’ve been use a similar architecture for a Flask app using SQLite and Redis. So far I haven’t had any issues sending thousands of events. The write process is a few milliseconds and from the docs iirc writes will get queued if there’s a lock. If it works for your case the simplicity of it is awesome. Unfortunately you don’t get things like RBAC so you need to use views and make sure your routes don’t allow access. Pushing security that I would probably prefer in the db to the app isn’t ideal imo.
Yes, it's a long presentation. Here's a good answer to your question:
> So, yes, it is actually possible to run full-featured Rails applications in production, with no compromises on features or performance, all on a single machine.
In other words, "stop worrying and just deploy a single application instance".
Author here: these are my original speaker notes and slides stitched together for the talk that I gave at Rails World 2024 in Toronto at the end of September. There is a link to the YouTube video at the top of the post. Unfortunately, the video doesn't display my slides as much as I was hoping, so I wanted to publish this post so that people can get the full message, as the slides are an important facet of the message.
Happy to talk anything about Rails 8 and SQLite.
Reading the title makes me think that I’m about to see an article about Pocketbase [0]. With the big refactoring in RC (v0.23.0), extending Pocketbase is going to be much better.
[0] https://pocketbase.io/
I only scrolled through this, and didn’t see an answer, but in this case more than one process can’t access the DB right? And presumably you’ve lost the ability to connect to the DB and poke around in the data?
Rails works with a connection pool and multiple threads processing incoming requests. Not a problem. In fact, Rails has one of the very best tunings to use SQLite in production in the context of a web application. And yes, you can also start a console session in production while your app is running. Just maybe don't make a long-running write query from within that console ;)
SQLite works fine with more than one process accessing the database, provided those processes are on the same machine and not attempting to coordinate over something like NFS.
You can connect to an in-use SQLite database using other tools (like the sqlite3 CLI tool or my https://datasette.io local web app) just fine.
The only thing to avoid is long running write operations, since those will block writes from other processes for their duration.
Enabling WAL mode avoids errors if you try to read while some other process is performing a write.
You can test this yourself: fire up a few terminal terminal windows and run sqlite3 multiple times against the same file on disk and see what happens.
Wal mode allows for concurrent readers and one writer. I’ve been use a similar architecture for a Flask app using SQLite and Redis. So far I haven’t had any issues sending thousands of events. The write process is a few milliseconds and from the docs iirc writes will get queued if there’s a lock. If it works for your case the simplicity of it is awesome. Unfortunately you don’t get things like RBAC so you need to use views and make sure your routes don’t allow access. Pushing security that I would probably prefer in the db to the app isn’t ideal imo.
You just provide an admin endpoint to download your DB. It makes a copy of the DB using VACUUM INTO clause and serves that. https://www.sqlite.org/lang_vacuum.html#vacuum_with_an_into_...
Apparently, this is also no longer necessary with the new replication tool, but haven't tried that.
Yes, it's a long presentation. Here's a good answer to your question:
> So, yes, it is actually possible to run full-featured Rails applications in production, with no compromises on features or performance, all on a single machine.
In other words, "stop worrying and just deploy a single application instance".