Solid Cable trades a service boundary for a database workload
Solid Cable can remove Redis from a Rails broadcast setup. Account for polling, message retention and recovery before calling the resulting system simpler.
By 
Paul. Architecture and infrastructure
Moving Action Cable broadcasts into a database can reduce the number of services a small Rails application operates. It also puts a new workload into the database estate. The right comparison is the total responsibility for delivering updates, including polling and message cleanup, rather than a count of infrastructure components.
Solid Cable's September 2024 integration made that trade-off concrete. Looking back from November 2026, the useful question is who will operate the broadcast path when the application is busy or a dependency fails. A simpler deployment diagram can be valuable, but it cannot answer that question by itself.
A development change to the production default
The Rails digest of 13 September 2024 described Solid Cable becoming the default Action Cable adapter in production in the developing framework. It explained that messages were stored in a table and continuously polled, allowing Redis to be removed when nothing else required it.
The originating Add Solid Cable pull request was merged on 12 September. “Development” here means work on the forthcoming Rails version. It does not mean that Solid Cable became the default adapter for the application's development environment. Nor did the merge automatically reconfigure existing applications.
Rails 8.0's final release followed on 7 November 2024. Keep those dates separate: September established the direction in framework development, while November marks the final major release. A September news digest cannot establish that a stable Rails 8 application was already available then.
The current Solid Cable README, read in November 2026, describes production installation and configurable polling and retention. It recommends a separate database while documenting a single-database alternative. These mutable instructions explain the operating boundary today; their complete option list must not be attributed to the September merge.
Follow one update through the system
Consider an illustrative order-management application. A background job updates an order and broadcasts an instruction that should refresh an employee's screen. The application still needs a correct business record, a working broadcast transport and a browser able to receive the update. Moving the adapter changes one part of that chain.
With database-backed transport, broadcast messages become database writes and readers poll for changes. The database is doing useful coordination work, not merely replacing a name in the deployment configuration. Polling frequency, active listeners and message volume influence the workload that operators need to understand.
Do not estimate that workload from the number of users alone. A quiet office dashboard and a frequently updated collaborative interface can have very different message patterns. Include bursts and simultaneous listeners in a representative trial. No throughput or latency measurement was performed for this article, and the maintainers' performance claims are not a substitute for that trial.
Separate databases still need shared capacity decisions
A separate cable database can make schema and data management clearer. It does not necessarily imply a separate database server or an independent failure domain. If the application and cable workloads share a machine or service, they may still compete for storage, connections or processing capacity.
Write down what is actually isolated. The distinction matters when a broadcast burst coincides with ordinary order processing. The design should say which work must remain responsive and what degradation is acceptable. A late screen update and a failed order write have different business consequences even when users notice both on the same page.
A single-database configuration may be reasonable for a modest workload if its operating simplicity outweighs the coupling. That is a local trade-off to demonstrate, not an inherently careless choice. Equally, moving to a separate database should solve an identified management or capacity problem rather than merely make the diagram look safer.
Retention is part of running the transport
Messages stored in a table need a lifecycle. Decide how long transport data needs to remain and how old rows are removed using the selected version's supported behavior. Verify that cleanup actually keeps pace with the intended workload. A configured interval alone is not evidence that storage remains bounded in operation.
Treat message content deliberately as well. If broadcasts carry sensitive information, understand where those rows and any copies can persist. Prefer sending only what the client needs. This is an architectural recommendation; it does not assert a particular encryption or compliance property for the historical adapter.
Do not mistake a retained message table for a business event ledger. A transport's cleanup policy and a business record's retention policy serve different purposes. The application should have a defined way to recover its current screen state after interruption rather than assuming the broadcast channel will supply a complete history.
Removing Redis may save nothing elsewhere
The strongest counterargument is an existing, well-operated Redis service that other parts of the application still need. Replacing its Action Cable role leaves the service in place and adds database work. The migration may produce little operational saving while introducing a new path to diagnose.
An application with demanding fan-out or tight update deadlines also deserves a workload-based comparison. A database-backed adapter may fit, but a favorable general claim does not settle those requirements. Keep the existing transport when the evidence for changing it is weak. Consolidation earns its place through the work the team can operate reliably.
For a planned change, check broadcasts across the web and background-job processes, observe message buildup and exercise recovery after an interruption. Set acceptance criteria for visible update delay and effects on ordinary application work. These are proposed checks, not a report of tests carried out here.
A software maintenance brief should name the broadcast owner, the capacity boundary and the cleanup policy. Solid Cable can simplify the services that owner runs. The application still needs somebody who can explain where an update went and restore useful behavior when it does not arrive.