For the last decade, a production-ready Ruby on Rails application meant at least 2 infrastructure-level dependencies: a production-grade database like PostgreSQL, and a production-grade key-value store like Redis.

Up until recently, several framework features, and many community-favorite gems explicitly depended on Redis or an equivalent key/value store.

If you like to keep your stack simpler and costs down, I have good news: you only need a database now, at least for a long, long while.

Background Jobs

For most Rails developers, the default ActiveJob adapter has been sidekiq (even before ActiveJob was a thing). There are two alternatives that leverage your database:

• ​good_job: has been around for a few years, and explicitly uses PostgreSQL features. I've used it for both professional large-scale projects and bootstrapped personal ventures, and can vouch for its stability.
• ​solid_queue: a more recent contender, extracted from Basecamp by the team at Basecamp. It will become the default ActiveJob adapter in Rails 8. Unlike good_job, it's compatible with all 3 major DBMSes (MySQL, PostgreSQL, SQLite).

My recommendation: good_job has been around for longer, and having no personal experience with solid_queue, I can only recommend the former unless you can't or don't want to use PostgreSQL, or you explictly want to stick with framework defaults.

Action Cable Adapter

As for background jobs, the accepted default for your Action Cable backend was Redis. I was surprised to find out while browsing the documentation that PostgreSQL is now supported natively in Rails 7.

I've been using that in production for months, with no issues. With that being said, if you intend on heavily using Action Cable (for example, a lot of Turbo refresh broadcasts, or live activity features) and reach a large scale, this is the first implementation I'd recommend closely monitoring, and if performance were lacking, still skipping the Redis backend, and moving directly to any_cable.

Cache Adapter

Another future Rails 8 default, solid_cache, also from the team at Basecamp, comes to complete the trifecta by replacing Redis as your Rails cache adapter.

This one is an easy drop-in replacement, but cache entries do add up quickly. If you're worried about the size of your DB, it allows you to enforce size limits easily.

That's it for the adapters, but that's not all you're getting by betting on your database.

Additional benefits

Obviously, having one fewer infrastructure dependency to manage, monitor and pay for is already great.

You may have noticed however, that all 3 (jobs, cable, and cache) now have an official DB-backed (PostgreSQL-backed, to be fully transparent) adapter straight from the Rails team, that is or will become the default for new applications. By following this trend now, you're getting in on the ground floor and sticking more to The Rails Way™, meaning less complexity and compatibility headaches down the line.

But, for me, the biggest benefit is that if something is in your database, it can be mapped to ActiveRecord models. That's how both good_job and solid_queue can provide mountable UIs to manage your jobs so easily, and that's how I was able to build a UI to manage user-specific cache fragments in 30 minutes, for example.

That's it for this first issue of Solo Rails. If you think of anything to add to this subject, have any feedback or suggestions, hit me up on Twitter/X. Thanks for reading!

Build well, build smart, but spend more time playing.

— Kevin