By ByteBot
Rails 8 just eliminated Redis from its default stack, and SimpleThread went public with their migration from Redis to PostgreSQL-backed job queues. With 37signals processing 20 million jobs per day on PostgreSQL alone, the question isn’t whether database-backed queues work—it’s whether the “95% of apps don’t need Redis” claim holds up under scrutiny.
The Redis Complexity Tax
Redis has been the de facto standard for Rails background jobs for over a decade, powering Sidekiq on platforms from GitHub to Shopify. But SimpleThread’s migration story exposes a painful truth: Redis comes with operational baggage most applications don’t need.
Deploy, version, patch, and monitor a separate Redis server. Manage persistence strategies, memory limits, and eviction policies. Configure network connectivity and firewall rules. Set up high-availability clustering. Maintain separate backup and recovery procedures. For what? Processing a few hundred jobs per second that PostgreSQL could handle while you sleep.
The cost isn’t just the $20-500 monthly Redis hosting bill. It’s the cognitive overhead of context-switching between PostgreSQL and Redis—two databases with fundamentally different semantics and operational models. It’s the DevOps time spent on infrastructure that delivers zero user value.
The SKIP LOCKED Breakthrough
Database-backed job queues aren’t new. What’s new is that they finally work at scale, thanks to a PostgreSQL 9.5 enhancement that went criminally underappreciated: FOR UPDATE SKIP LOCKED.
The mechanism is elegant. FOR UPDATE creates an exclusive row lock on selected jobs. SKIP LOCKED tells competing workers to skip locked rows instead of waiting. Multiple workers query the jobs table simultaneously. Each claims unique jobs without blocking. No lock contention. No thundering herd. No performance collapse.
This single SQL clause makes SolidQueue viable where previous database queue implementations failed. 37signals isn’t running a toy workload—they’re processing 20 million jobs per day (roughly 230 per second) entirely on PostgreSQL. That’s not Redis performance, but it’s sufficient for the vast majority of Rails applications.
The 95% Reality Check
SimpleThread claims “95% of apps don’t need Redis for background jobs.” The Hacker News debate shows this claim is both directionally correct and frustratingly imprecise.
The supporting evidence is compelling. Most Rails apps process under 100 jobs per second. Email sends, report generation, data syncs, image processing—these workflows tolerate 100ms latency just fine. SolidQueue handles this load while eliminating an entire infrastructure dependency.
But the counterexamples matter. One developer reported PostgreSQL-backed queues hitting performance walls at 2,000-5,000 jobs per minute—far below Redis+Sidekiq capabilities. Another noted that spiky traffic patterns (Black Friday sales, ticket releases) can overwhelm database queues in ways Redis shrugs off.
The nuance: “95%” isn’t a technical threshold. It’s a statement about application distribution. If your workload peaks below 1,000 jobs per second and you can tolerate 100ms latency, SolidQueue works. If you’re processing thousands of jobs per second sustained or require sub-millisecond latency for high-frequency trading or real-time bidding, Redis remains the only viable option.
Context matters more than percentages.
The Business Case
SolidQueue delivers immediate cost savings. Sidekiq Enterprise charges $949-$1,699 annually for features like concurrency limits and rate limiting—features SolidQueue includes by default. Redis hosting ranges from $20 monthly for small instances to $500+ for production-grade clusters. Those costs vanish entirely with SolidQueue.
The operational savings compound. One fewer service to deploy. One fewer connection pool to manage. One fewer backup strategy. One fewer monitoring dashboard. For small teams, this is the difference between shipping features and fighting infrastructure.
But Redis hasn’t lost yet. Sidekiq powers GitHub, Shopify, and Airbnb—platforms processing orders of magnitude more jobs than SolidQueue’s proven capacity. The monitoring tools are mature. The performance ceiling is higher. The multi-language ecosystem means Redis works beyond Rails.
The decision framework is straightforward: choose SolidQueue for new Rails 8 applications unless you have proven workload requirements exceeding 1,000 jobs per second. Migrate existing applications only if Redis is actively causing operational pain. Stick with Redis if you’re already running it successfully at scale—migration risk rarely justifies marginal simplification gains.
The Rails Simplification Bet
SolidQueue isn’t isolated. Rails 8 systematically eliminates Redis across the entire framework. SolidCache replaces Redis for caching. SolidCable replaces Redis for ActionCable WebSockets. The Solid* family runs entirely on PostgreSQL.
This represents a philosophical bet: operational simplicity beats architectural purity. Consolidate on fewer, better-understood services instead of microservices sprawl. Leverage existing infrastructure rather than adding dependencies.
The parallel to the PaaS-first movement is unmistakable. Platforms like Fly.io and Render argue that Kubernetes complexity is overkill for most applications. Rails 8 argues that Redis is overkill for most background jobs. Both movements champion “boring technology”—using fewer pieces that work predictably over cutting-edge architecture that requires specialist knowledge.
Whether this bet pays off depends on whether the simplicity gains offset the performance ceiling. For 37signals running HEY at 20 million jobs per day, the answer is clearly yes. For teams hitting PostgreSQL’s scaling limits, the answer is clearly no.
The rest of us live in the 95% middle—where operational pragmatism matters more than architectural elegance, and one fewer service to manage beats bragging rights about job queue latency.
