Anybody have any opinions on moving away from Redis for cables/caching/jobs?
I supposed it'd be nice to have one less thing to manage, but I'm wondering if there are any obvious gotchas to moving these features over to sqlite and postgresql.
For caching specifically solid_cache works better for long lived and larger caches than does Redis. If you need short lived and smaller caches Redis will be more performant for you.
That said you can probably get away with caching way more with solid_cache and it's highly dependent on what your use cases are.
Also a thing to note that your DB backing solid_cache might also be using RAM efficiently, giving you a lot of benefits that Redis did.
For new projects I'll be using solid_cache first and adding Redis only on an as-need basis. The cost of Redis is orders of magnitude higher than a DB backed cache.
DHH mentioned 10TB of cache and only 0.5ms increase in latency difference between Redis and SQLite. I wish other could test it out and have some other figures to point to. But if the stated case were true then I think sacrifice 0.5ms for 10 to 20x more cached resources sounds like a very good deal to me.
I had a bad experience with Action Cable + Redis (extremely high memory overhead, tons of dead redis connections), so it's a bit "fool me once" with regard to action cables.
The main argument for caching in the DB (the slight increase in latency going from in-memory->DB-in-memroy is more than countered by the DB's cheapness of cache space allowing you to have tons more cache) is one of those brilliant ideas that I would like to try at some point.
Solid job - i just am 100% happy with Sidekiq at this point, I don't understand why I'd switch and introduce potential instability/issues.
I have used both with rails. (Cable is still going through Redis tho).
Solid cache is perfect for my use case since page caches doesn't change as often, so taking a smaller memory footprint on the server farm is a win.
My take is to measure your cache hit percentage. This will allow anyone to understand their cache eviction rates. If you have high eviction rates maybe using a btree is not the way to go and redis is probably better
I havent used them, and we are not moving to them on our existing app but I can super-appreciate the fact that by default redis is more of a down-the-road decision now. No reason to get into the complexity (+ additional hosting cost) of adding another service into the mix until you choose to later on.
On Rails homepage, it says from “Hello World” to IPO. The idea is that Rails should help you maintain a lean stack by default. You can stick with Postgres for pretty much everything: caching, background jobs, search, WebSockets, you name it.
But, as your app grows, you can swap things out. Redis or Elasticsearch are solid choices if you need them. DHH mentioned that as well, at scale, everyone does things differently anyway. But you do have the option to keep it simple, by default.
For me personally, Rails 8 is great. My new project only need Postgres and that's it. I don't need Redis, multiple gems for background jobs or cache anymore. Able to avoid the chaotic JS ecosystem for frontend. Hopefully it will be easy to setup Hotwire Native too. It really streamlined things, and letting me focus on building features instead.
That said, for my production apps in existing companies, I’m sticking with what’s already working: Sidekiq, Redis, Elasticsearch. If it ain’t broke, why fix it? Will probably revisit this decision again in the future. Too early to tell for now.
Regarding Hotwire Native: I tried Strada a few months ago, but I never got it to work. Hotwire Native was running within 10 minutes on each platform. The docs are miles ahead of the Strada docs imo.
Totally makes sense not to jump in early to make sure kinks are worked out, but it is worth noting that Solid Cache was code extracted from BaseCamp and HEY, so it has seen production at scale for a while now.
I supposed it'd be nice to have one less thing to manage, but I'm wondering if there are any obvious gotchas to moving these features over to sqlite and postgresql.