The final Solid gem to explore is Solid Cable, which powers the Pub/Sub server that drives Action Cable—the system responsible for sending WebSocket messages to connected clients.

Understanding the Solid Cable Schema

If we first examine our schema file, we see that, like Solid Cache, Solid Cable has a simple single-table schema. If you're interested, you can study the details further, but in short, this schema is well-designed for managing WebSocket messages efficiently.

Looking at the configuration file, we see that different adapters are used in development and production.

• Development: Uses the Async adapter instead of Solid Cable
• Production: Connects to a separate database—the cable database, not the primary database
• Polling Mechanism: It polls every 100ms and retains messages for one day

How Solid Cable Improves Performance

One key takeaway is that Solid Cable uses a polling-based system, rather than a listen/notify system like PostgreSQL. However, because it is a separate database, its reads and writes operate in parallel to:

• Primary Database Queries
• Cache Reads/Writes
• Job Queue Processing

This separation of concerns ensures maximum performance, reduces bottlenecks, and maintains system stability.

Why This Approach Is So Powerful

The best part of this setup is that all of these databases use SQLite, meaning they are simply files on disk. This eliminates additional operational complexity—there’s no need to configure extra servers, and everything runs seamlessly on both local development and production environments.

This simplicity and efficiency is what makes Rails 8's new defaults so exciting.

Next Steps: Docker & Deployment

Before we begin building our application, the last two things I want to explore from the scaffolded Rails 8 project are:

• The new Docker file
• The new Kamal deployment tool

Once we’ve covered those, we’ll dive into building the application together.