Rails on SQLite: exciting new ways to cause outages
This post was originally given as a talk for Friendly.rb. The slides are also available.
Between Litestack and the Rails 8 trifecta of Solid Cable, Solid Cache, and Solid Queue, it’s easier than ever to spin up a Rails app that doesn’t need a database service, or a redis service, or a file storage service. It’s great to simplify things, but even after 20 years of deploying Rails apps I was still caught out by some of the ways things are different.
Based on what happened when I built a new side project in Rails on SQLite, we’ll cover what’s different, what’s new, and several ways that you can knock your site offline or even destroy your entire production database. As we go, we’ll also talk about the advantages of using SQLite, and how those differences can help you.
So who am I, how did I learn these things, and why should you listen to me? I’m André Arko, better known on the internet as @indirect. A long time ago, I helped create Bundler, and I’ve been the OSS team lead for RubyGems and Bundler for more than a decade at this point.
I work at Spinel Cooperative, a collective of Ruby open source maintainers building rv, the Ruby language manager that can install Ruby in one second flat. We offer retainers for unlimited access to core team experts from Bundler, Rails, Hotwire, and more, who can answer your questions and solve your problems.
I’ve been deploying Rails applications to production since 2004, and most relevantly for this particular talk, I built a service called feedyour.email. Feed Your Email turns email subscriptions into RSS feeds that you can subscribe to in your feed reader. There is no signup, there are no accounts, you just go to the website and push a button to get an email address and a feed URL. Emails sent to that address will show up in that feed.
Feed Your Email is only possible as a service because of SQLite—if I had to maintain three Postgres instances and a couple of web instances and a couple of worker instances, I would have felt like it was too much hassle and cost too much money, and given up. SQLite reduced the complexity of building and deploying this service to the point where I was able to do it casually, for fun, and keep it running for everyone while feeling like it was worth it just for my own personal use.
This app serves about a million requests per month. That number sounds kind of big, but let’s do the math: 24 requests per minute, or one every 2.6 seconds. We can definitely serve at least one request every 2.6 seconds off of our Rails app, even on a small digital ocean droplet or a small cloud VM. I run my service on Fly.io, and hosting costs about USD$14 per month.
It has bonus features like a web view so you can share individual emails as a link without giving away your secret email address or letting anyone see the other emails in that feed, and it also has full-text search if you’re trying to find a particular email. That full-text search is a feature of SQLite, which brings us back to the topic of this talk. How did SQLite help? Let’s take a look.
... continue reading