DEV Community: Sebastian Jimenez

Deploying Rails 8's Solid Trio to Production with a Single Database

Sebastian Jimenez — Fri, 06 Mar 2026 07:01:00 +0000

Deploying Rails 8's Solid Trio to Production with a Single Database

Rails 8 ships with the Solid stack — Solid Cache, Solid Cable, and Solid Queue — replacing Redis for caching, WebSockets, and background jobs. Database-backed infrastructure with zero external dependencies.

Development was smooth. Production wasn't. This post documents the issues we ran into deploying the Solid trio to a Hatchbox-hosted app with a single PostgreSQL database, the mistakes we made debugging them, and what ultimately fixed things.

The Setup

Rails 8 with Hotwire (Turbo + Stimulus)
PostgreSQL 18 in production, 17 locally
Hatchbox for deployment (single provisioned database)
Solid Queue, Solid Cache, and Solid Cable

The app is a booking system. Admins manage bookings, and Turbo broadcasts push real-time status updates when bookings are confirmed or cancelled.

Problem 1: Missing Tables

The first error appeared on the first request that touched caching:

PG::UndefinedTable: ERROR: relation "solid_cache_entries" does not exist

What happened

When you run rails solid_cache:install, it generates:

config/cache.yml — the configuration
db/cache_schema.rb — the table definition

There's no migration file. The official approach is to configure a separate cache database in database.yml and run db:prepare in production, which loads schema files for secondary databases.

Our deploy platform, Hatchbox, runs db:migrate — not db:prepare. And db:migrate only runs migration files from db/migrate/. It doesn't load schema files.

The same was true for Solid Cable and its db/cable_schema.rb.

Why it worked locally

In development, the databases had been set up with db:prepare when the project was first created. The tables existed. We never noticed they weren't created through migrations.

Problem 2: One Database, Four Configs

Our database.yml in production had separate entries for each Solid gem:

production:
  primary:
    url: <%= ENV["DATABASE_URL"] %>
  cache:
    url: <%= ENV["DATABASE_URL"] %>
    migrations_paths: db/cache_migrate
  cable:
    url: <%= ENV["DATABASE_URL"] %>
    migrations_paths: db/cable_migrate
  queue:
    url: <%= ENV["DATABASE_URL"] %>
    migrations_paths: db/queue_migrate

This looks like four databases, but they all point to the same DATABASE_URL. Hatchbox provisions one database. We weren't running separate databases — we were running separate configurations pointing to the same database.

The migrations_paths entries pointed to folders like db/cache_migrate/ and db/cable_migrate/. These folders were empty. The actual table definitions lived in schema files, which db:migrate ignores.

What We Did

The official separate-database approach

The Solid Cache and Solid Cable READMEs recommend separate databases with db:prepare. That's the standard approach and it works well when your hosting allows provisioning multiple databases.

We couldn't do that. Hatchbox gives us one database and runs db:migrate.

The single-database workaround

Both READMEs document what to do in this case. From the Solid Cache README:

"When you omit database, databases, or connects_to settings, Solid Cache automatically uses the ActiveRecord::Base connection pool."

Solid Cable's README is more explicit:

"Copy the contents of db/cable_schema.rb into a normal migration and delete db/cable_schema.rb"

This isn't the primary recommended approach — it's a workaround for single-database setups. But it's documented and it works.

Here's what we did:

1. Created regular migrations in db/migrate/:

# db/migrate/20260306054425_create_solid_cache_entries.rb
class CreateSolidCacheEntries < ActiveRecord::Migration[8.0]
  def up
    load Rails.root.join("db/cache_schema.rb")
  end

  def down
    drop_table :solid_cache_entries
  end
end

# db/migrate/20260306062125_create_solid_cable_messages.rb
class CreateSolidCableMessages < ActiveRecord::Migration[8.0]
  def up
    load Rails.root.join("db/cable_schema.rb")
  end

  def down
    drop_table :solid_cable_messages
  end
end

A note on this approach: loading the schema files uses force: :cascade, which drops and recreates the table if it already exists. For a first-time setup this is fine, but for an established database you may want to copy the table definition explicitly instead. The Solid Cable README recommends the explicit copy approach.

2. Removed separate database configs from production database.yml:

production:
  primary:
    <<: *default
    url: <%= ENV["DATABASE_URL"] %>
  queue:
    <<: *default
    url: <%= ENV["DATABASE_URL"] %>
    migrations_paths: db/queue_migrate

We kept queue because Solid Queue ships with actual migration files in db/queue_migrate/, unlike Cache and Cable which only have schema files.

3. Removed connection directives:

# cable.yml — removed connects_to block
production:
  adapter: solid_cable
  polling_interval: 0.1.seconds
  message_retention: 1.day

# cache.yml — removed database: cache
production:
  <<: *default

With these changes, db:migrate creates the tables and both gems fall back to the primary connection pool.

Problem 3: A Misleading Error

After fixing the cache table, we hit a new error when cancelling bookings from the admin panel:

ArgumentError: No unique index found for id

The top of the stack trace pointed to our Turbo broadcast code:

def broadcast_status_update
  broadcast_replace_to(
    self, "status",
    target: "booking_status",
    partial: "bookings/status",
    locals: { booking: self }
  )
end

Our bookings table uses UUID primary keys. We assumed the problem was that ActiveRecord couldn't find a unique index on the UUID id column. We spent time trying various workarounds:

Switching to Turbo::StreamsChannel.broadcast_replace_to with string-based channel names
Rendering HTML with ApplicationController.render instead of passing partial:
Adding an explicit unique index on bookings.id

None of it worked.

What actually happened

We eventually pulled the full stack trace from Bugsnag:

activerecord/insert_all.rb:165:in `find_unique_index_for'
  ...
solid_cable/message.rb:15:in `broadcast'
solid_cable/lib/action_cable/subscription_adapter/solid_cable.rb:19:in `broadcast'
  ...
turbo-rails/app/channels/turbo/streams/broadcasts.rb:13:in `broadcast_replace_to'
app/models/booking.rb:174:in `broadcast_status_update'

The error wasn't in our code. It was in Solid Cable. When our broadcast fired, Turbo handed the message to Action Cable, which handed it to Solid Cable, which tried to insert into the solid_cable_messages table. That table didn't exist yet — the Solid Cable migration hadn't been deployed at that point.

We're not 100% certain about the exact mechanism — whether the error was because the table was missing entirely or because the table existed without proper indexes. The error message ("No unique index found for id") suggests an index issue, but a missing table could also surface differently depending on how ActiveRecord checks for indexes. What we know for certain is that once the migration ran and the table was properly created, the error went away.

What we learned

Read the full stack trace. The error message and top frame made it look like a UUID primary key problem on our bookings table. We spent time adding indexes and rewriting broadcast code. The actual cause was several frames deep in a gem we hadn't thought to check.

It's also a reminder that errors don't always mean what they say. "No unique index found for id" led us to chase index problems when the underlying issue was a missing table.

A note on `db:prepare` and schema files

During debugging, we also tried switching our deploy command to db:prepare, thinking it would load the schema files. It's worth noting that there are known inconsistencies with how db:prepare handles secondary database schema files. It may not work reliably in all scenarios. The migration approach we ended up with, while not the primary recommended path, turned out to be more predictable.

There's also a known Rails issue where running db:migrate can erroneously empty secondary schema files like queue_schema.rb. Something to watch out for if you're keeping Solid Queue on a separate database config.

Verifying Everything Works

After deploying, we verified each component via the Rails console:

# SolidCache
Rails.cache.write("test_key", "hello")
Rails.cache.read("test_key")
# => "hello"

# SolidCable
SolidCable::Message.count
# => 0

# The original failing action — cancelling a booking
booking = Booking.confirmed.last
booking.soft_delete!(AdminUser.first)
# => No error

Summary

If you're deploying Rails 8's Solid trio to a single-database environment where db:migrate is your deploy command:

Check your deploy command. If it runs db:migrate (not db:prepare), schema files for Solid Cache and Solid Cable won't be loaded. You need regular migrations.
Create migrations for Solid Cache and Solid Cable. The Solid Cable README documents this: copy the table definitions from db/cable_schema.rb into a standard migration. Same for Solid Cache. This is a documented workaround for single-database setups, not the primary recommended approach.
Remove separate database configs from database.yml if you're using one database. Remove connects_to from cable.yml and database from cache.yml. Both gems will fall back to the primary connection pool.
Keep Solid Queue's separate config. Solid Queue ships with actual migrations in db/queue_migrate/ that db:migrate can find.
Read the full stack trace. When debugging production errors with the Solid stack, the error origin might be several frames deep in a gem you didn't expect. Don't assume the top frame tells the whole story.

Final Thoughts

The Solid trio works well once properly set up. The default Rails 8 configuration assumes you can provision multiple databases and run db:prepare — a reasonable assumption, but not universal. If your hosting doesn't support that, the workaround is straightforward and documented, though not prominently.

We made our debugging harder by not reading the full stack trace early enough. The lesson there is universal, not specific to the Solid stack.

I made a thing for recording demos from the browser. No app install required.

Sebastian Jimenez — Wed, 18 Feb 2026 07:57:00 +0000

The problem nobody talks about

You just shipped something. Maybe it's a side project, maybe it's a feature at work. You want to show it off. Simple, right?

Not really.

The usual flow looks something like this: find a screen recording app, download it, install it, figure out the settings, hit record, mess something up, re-record, then open
another app to trim and edit. Oh, and half the decent options want your credit card before you even get started.

All of that just to get a 30-second clip you can share in a tweet or a PR description.

What I actually wanted

A way to record a quick demo and get a shareable video out of it. No installs. No editing rabbit holes. No paywall.

That's it. That was the whole requirement.

I looked around for a while and everything I found either had too much friction or too many strings attached. So I did what any reasonable developer would do and built the
thing myself.

Recall

I put together Recall to solve exactly this. You open it, record your demo, and get a shareable video. The whole point is to stay out of your way.

It's free, no limits, no account required.

If you're someone who builds things and wants a fast way to show what you're working on, give it a shot. I'd genuinely love to hear what you think and what would make it
more useful for your workflow.

Link: https://recall.sebastianjimenez.co/

Catch N+1 Queries in Rails Request Specs with 11 Lines of Ruby

Sebastian Jimenez — Sun, 01 Feb 2026 05:23:55 +0000

Catch N+1 Queries in Rails Request Specs with 11 Lines of Ruby

N+1 queries are one of the most common performance pitfalls in Rails applications. Tools like Bullet and Prosopite can help detect them, but they add dependencies and configuration overhead. Sometimes you just want a lightweight, transparent way to assert on query counts directly in your request specs.

Here's how to do it with nothing more than what Rails already gives you.

The Technique

Rails instruments every SQL query through ActiveSupport::Notifications under the sql.active_record event. We can subscribe to that event for the duration of a block and collect every query that fires.

Create a file at spec/support/query_counter.rb:

module QueryCounter
  def capture_queries(&block)
    queries = []
    callback = lambda do |_name, _start, _finish, _id, payload|
      queries << payload[:sql] unless payload[:sql].match?(/SCHEMA|BEGIN|COMMIT|SAVEPOINT|RELEASE/)
    end

    ActiveSupport::Notifications.subscribed(callback, "sql.active_record", &block)

    queries
  end
end

RSpec.configure do |config|
  config.include QueryCounter, type: :request
end

That's it. The key method here is ActiveSupport::Notifications.subscribed, which temporarily subscribes a callback for the duration of the block and automatically unsubscribes afterward. The regex filter excludes noise — schema introspection and transaction control statements — so you're left with only the queries your application code actually triggers.

Using It in a Spec

Suppose you have an endpoint that returns a post with its comments. A naive implementation might load the post, then issue a separate query for each comment — the classic N+1. Here's how you'd catch that:

RSpec.describe "Posts API", type: :request do
  let!(:posts) { create_list(:post, 5, :with_comments) }
  let(:target_id) { posts.last.id }

  it "avoids N+1 queries when fetching post details" do
    queries = capture_queries { get "/api/posts/#{target_id}" }

    comment_queries = queries.count { |q| q.include?("comments") }
    expect(comment_queries).to eq(1)
  end
end

The test makes the request inside capture_queries, then filters the collected SQL strings to count how many hit the comments table. If someone removes an includes call or introduces a lazy load, this test fails.

Why This Works Well

It's explicit. Instead of relying on a background tool to warn you, you're making a direct assertion. The intent is clear to anyone reading the spec.

It tests the full stack. Because this runs inside a request spec, you're exercising the actual controller, serializer, and any eager loading — not a unit test on an isolated query.

It gives you the raw SQL. The queries array contains the actual SQL strings, so when a test fails, you can inspect exactly what fired. This makes debugging straightforward:

queries = capture_queries { get "/api/posts/#{target_id}" }
puts queries # see every query that ran

No dependencies. This uses ActiveSupport::Notifications, which is part of Rails. There's nothing to install, configure, or keep up to date.

Limitations

This approach is intentionally minimal. It doesn't automatically detect N+1s — you have to know what to assert on. It doesn't give you RSpec matchers like expect { }.to execute_queries(at_most: 3). And it won't alert you to regressions unless you've written a test for that specific endpoint.

For projects that need automatic detection across every request, tools like Prosopite or Bullet are better suited. But for targeted assertions on critical endpoints, 12 lines of Ruby and a clear test go a long way.

Tips for Adoption

Start with your slowest endpoints. Add capture_queries to the request specs for endpoints you know are performance-sensitive.
Assert on specific tables. Counting all queries is brittle — a schema change might add or remove a join. Filtering by table name (like the comments example above) makes tests more resilient.
Use it during development. Wrap a controller action in capture_queries in a scratch test to see what's actually happening before you optimize.

The best performance tools are the ones you'll actually use. Sometimes that's a full-featured gem. Sometimes it's 12 lines in spec/support.

Thanks for reading this far!

I'm currently exploring solutions for my own problems. I recently created shaicli.dev and frost. Please check them out, I'd love to know what you think!

I got mass downvoted for sharing my Claude configuration. So I built a tool to fix this.

Sebastian Jimenez — Wed, 24 Dec 2025 04:02:00 +0000

Last month I shared my Claude Code configuration on Reddit.

The response?

"Cool but how do I actually use this?"
"Can you just give me the files?"
"Where do I put these?"

I spent 30 minutes answering the same questions. Then someone asked me to update it. Then someone forked my gist and it got out of sync.

I mass-deleted my comments and rage-quit the thread.

The problem nobody talks about

Every dev using AI coding tools has this workflow:

Find someone's config that looks useful
Copy-paste from a gist/notion/tweet thread
Figure out where the files go
Realize it's outdated
Give up and write your own

We've solved package management, dotfiles, and infrastructure-as-code. But AI configurations? Still living in the dark ages of copy-paste.

What if it was just one command?

shai install anthropic/claude-expert

That's it. Files land exactly where they belong. No cloning repos. No navigating folders. No "where does this go?"

✓ Created .claude/
✓ Created .claude/settings.json
✓ Created CLAUDE.md
✓ Installed 6 items from anthropic/claude-expert

I built Shai in a weekend

Shai is a CLI for sharing AI configurations.

shai search "rails" → find configs others have shared
shai install user/config → install with one command
shai push → share your own setup

No login required to search or install public configs. Takes 10 seconds to set up:

curl -fsSL https://shaicli.dev/install.sh | bash

Why not just use Git?

You could store configs in a Git repo. But when you want someone else's config:

Git	Shai
Clone repo, find files, copy them	shai install user/config
Need the repo URL upfront	Search and discover
Get README, LICENSE, CI files, .git	Get just the config files

Git is for code you develop. Shai is for configs you use.

Show me your setup

I'm building a library of community configurations. Here's what I'm looking for:

Claude Code setups for:

Rails / Django / Next.js / Laravel
Mobile (React Native, Flutter, Swift)
DevOps / Infrastructure
Data Science / ML

Cursor configurations for:

Specific frameworks
Code review workflows
Testing patterns

If you have a config worth sharing:

shai login
shai init
shai push

Drop your username/config in the comments. I'll feature the best ones on the https://shaicli.dev/explore.

The first 50 configs get featured

I'm hand-picking the first 50 public configurations to feature on the homepage. If you publish this week, you're basically guaranteed a spot.

What makes a good config:

Actually works (tested it yourself)
Has a clear use case (not "my random settings")
Includes a description

Try it now

Install (10 seconds)

curl -fsSL https://shaicli.dev/install.sh | bash

Search configs

shai search "claude"

Install one

shai install community/claude-for-rails

Share your own

shai login
shai init
shai push

Links:

🌐 https://shaicli.dev
📦 https://github.com/infinitlab/shai-cli
📚 https://shaicli.dev/docs

What's your current AI config workflow? I'm curious how others are handling this. Drop a comment below.

DEV Community: Sebastian Jimenez

Deploying Rails 8's Solid Trio to Production with a Single Database

Deploying Rails 8's Solid Trio to Production with a Single Database

The Setup

Problem 1: Missing Tables

What happened

Why it worked locally

Problem 2: One Database, Four Configs

What We Did

The official separate-database approach

The single-database workaround

Problem 3: A Misleading Error

What actually happened

What we learned

A note on db:prepare and schema files

Verifying Everything Works

Summary

Final Thoughts

I made a thing for recording demos from the browser. No app install required.

Catch N+1 Queries in Rails Request Specs with 11 Lines of Ruby

Catch N+1 Queries in Rails Request Specs with 11 Lines of Ruby

The Technique

Using It in a Spec

Why This Works Well

Limitations

Tips for Adoption

Thanks for reading this far!

I got mass downvoted for sharing my Claude configuration. So I built a tool to fix this.

Install (10 seconds)

Search configs

Install one

Share your own

A note on `db:prepare` and schema files