The Redis Exodus: Why We're Returning to Database-Backed Queues

# The Redis Exodus: Why We're Returning to Database-Backed Queues ## — Commercial License Changes and the Return to Second-Generation Queue Management Something interesting happened in our industry recently. Redis, the in-memory data store that became synonymous with modern web architecture, suddenly feels less inevitable than it once did. The licensing changes and operational costs have prompted many e-commerce platforms to reconsider what was once an obvious choice. In the Rails community especially, the "Redis or nothing" mentality is giving way to something more nuanced. … |Licensing|Previously fully open source.|Commercial feature licensing changes raise future uncertainty concerns.| **Key Point**: Redis still excels in many use cases like caching and pub/sub. However, the reality in 2025 is that more workloads can conclude "persistent layer in DB, queues in DB too" is sufficient. ## Rethinking Infrastructure Costs and Maintenance Load **Physical Costs:** Being in-memory means data volume equals memory requirements. As application count and transactions increase, costs scale accordingly. **Operational Costs:** Building and maintaining Redis Sentinel/Cluster configurations, handling failures, and managing version upgrades requires specialized knowledge separate from RDB operations. Even cloud services require ongoing management.