Redis Loses Rails Jobs to SolidQueue as License Shift Bites

Redis Loses Rails Jobs to SolidQueue as License Shift Bites

A widely-read blog post from SimpleThread documented its team's migration from Redis to SolidQueue for background job processing. The decision was driven by Redis's switch to a source-available license, which introduced uncertainty and cost that SolidQueue β€” built directly on PostgreSQL β€” avoids entirely.

In January 2026, a prominent Ruby on Rails consultancy publicly declared it was abandoning Redis for SolidQueue, citing the licensing change Redis imposed in 2024. The move crystallizes a growing rift: developers who once loved Redis for its simplicity now see it as a legal and operational liability.
  • SimpleThread, a respected Rails consultancy, published a detailed account of migrating from Redis to SolidQueue for job queues, citing licensing and operational overhead as primary reasons.
  • Redis's 2024 license change from BSD to a source-available model (RSALv2/SSPL) created legal friction for hosted and commercial users, pushing teams to seek alternatives.
  • SolidQueue, which uses PostgreSQL as its backend, eliminates the need for a separate Redis process, reducing complexity and cost for Rails applications already on Postgres.

Why Did SimpleThread Decide to Drop Redis After Years of Loyalty?

According to SimpleThread's January 2026 blog post, the decision was not about Redis's technical merits β€” the team still considers Redis fast and reliable. The trigger was the licensing change that Redis (now Redis Ltd.) enacted in March 2024, moving from the permissive BSD license to a dual-license model under the Redis Source Available License v2 (RSALv2) and SSPL. For a consultancy that deploys applications for clients who may eventually want to offer Redis as a managed service, that change introduced legal review costs and deployment restrictions that SimpleThread deemed unacceptable. The team also noted operational fatigue: maintaining a separate Redis process for job queues β€” when PostgreSQL was already handling data persistence β€” felt increasingly wasteful.

What Is SolidQueue and Why Does It Threaten Redis in Rails?

SolidQueue is a job queue library for Ruby on Rails built directly on top of PostgreSQL, using its native locking mechanisms to manage concurrent workers. It was introduced by the Rails core team and is now bundled with Rails 8.0. The key architectural difference is that SolidQueue requires no separate server or data store β€” if your application uses PostgreSQL, you already have everything you need to run SolidQueue. According to the Rails documentation, SolidQueue uses PostgreSQL's SKIP LOCKED feature for job polling, which provides sufficient throughput for the vast majority of Rails applications. Redis can handle tens of thousands of job dispatches per second; SolidQueue handles thousands. For most teams, that difference is irrelevant.

Redis Loses Rails Jobs to SolidQueue as License Shift Bites

Does Redis's Licensing Change Actually Matter for Most Developers?

Redis Ltd. reported in its 2024 license update that the change was intended to prevent cloud providers from offering Redis-as-a-service without contributing back. For developers running Redis locally or on a single server, nothing changed. But for consultancies, SaaS providers, and anyone deploying Redis in a commercial hosting environment, the new license introduced ambiguity. According to the Redis Ltd. FAQ on the license change, the RSALv2/SSPL license is not considered open source by the Open Source Initiative (OSI). That means developers who rely on OSI-approved licenses for compliance or legal review must now treat Redis differently. SimpleThread's post explicitly called this out: 'We can't recommend a tool to clients that might trigger a legal review every time they deploy.'

How Does SolidQueue Compare to Redis for Background Jobs?

DimensionRedis (Sidekiq)SolidQueue (PostgreSQL)
Throughput (jobs/sec)10,000+~2,000 (estimated)
LicenseRSALv2/SSPL (source-available)MIT (open source)
Infrastructure dependenciesRequires separate Redis serverOnly PostgreSQL (already deployed)
Operational complexityModerate (monitoring, backup, memory tuning)Low (uses existing DB tooling)
Ecosystem maturityMature, extensive communityNew (bundled with Rails 8, 2024)
VerdictWinner for high-throughput or multi-service architecturesWinner for simplicity, cost, and license certainty in Rails-only stacks

What Does This Migration Tell Us About the Broader Infrastructure Market?

The SimpleThread migration is a microcosm of a larger shift: developers are increasingly optimizing for simplicity and license safety over raw performance. Redis is not in danger of disappearing β€” it powers caching, real-time analytics, and high-frequency job queues at massive scale. But in the Rails job-queue niche, where Redis's speed advantage is often unnecessary, SolidQueue's zero-dependency approach is a compelling alternative. According to the Ruby on Rails community survey (2025), approximately 60% of Rails applications already use PostgreSQL as their primary database. For those teams, adding Redis for job queues was always a convenience choice, not a necessity. SolidQueue removes that convenience tax.

My thesis: Redis's licensing change was a strategic miscalculation that accelerated the very commoditization it was meant to prevent, and SolidQueue is the first clear beneficiary in the Rails ecosystem. In the short term, Redis Inc. will see minimal revenue impact because its enterprise customers are locked into higher-value use cases (caching, session stores, real-time streams). But in the long term β€” within 18 to 24 months β€” I expect SolidQueue (or a PostgreSQL-based competitor) to capture at least 25% of new Rails job-queue deployments, eroding Redis's mindshare among the next generation of developers. The winners here are PostgreSQL (which gains another reason to be the default database) and the Rails core team (which reduces external dependencies). The losers are Redis Inc. (which loses a beachhead in the Rails community) and Sidekiq (the popular Redis-based job library), which will see declining growth as SolidQueue becomes the default in Rails 8. I infer this from the pattern of developer behavior: once a solution is bundled as the default (like SolidQueue in Rails 8), adoption follows a power law, regardless of technical superiority.

  1. Prediction 1: By December 2027, SolidQueue will be the job queue of choice for over 30% of new Rails 8 applications, with Redis/Sidekiq dropping below 50% for the first time in that segment.
  2. Prediction 2: Redis Inc. will introduce a free tier or relaxed license terms specifically for job queue use cases within 12 months, in an attempt to stem the migration.
  3. Prediction 3: At least one major cloud provider (AWS, GCP, or Azure) will announce a PostgreSQL-native job queue service by mid-2027, validating SolidQueue's architectural approach.

Article Summary

  • SimpleThread's migration from Redis to SolidQueue is a signal, not an outlier: it represents a broader developer preference for license simplicity and reduced operational overhead.
  • Redis's licensing change, while strategically aimed at cloud providers, has collateral damage among consultancies and SaaS teams that now avoid Redis for new projects.
  • SolidQueue's bundling in Rails 8 gives it a distribution advantage that Redis cannot match, regardless of technical performance.
  • The PostgreSQL ecosystem gains another 'good enough' component, reducing the need for specialized infrastructure in standard Rails deployments.
  • Redis remains irreplaceable for high-throughput caching and real-time workloads, but its dominance in job queues is ending.

Source and attribution

Hacker News
I Love You, Redis, but I'm Leaving You for SolidQueue

Discussion

Add a comment

0/5000
Loading comments...