Every Rails app starts out fast. Then features ship, data grows, and one day someone says the words no team wants to hear: "the app feels slow." If that's where you are, the good news is that Rails apps tend to slow down for a fairly predictable set of reasons. This post is a quick tour of the usual suspects — not a deep dive, just enough to know where to look first.
1. The database is almost always suspect number one
For most Rails apps, the bottleneck isn't Ruby — it's the database. A query that was instant with 10,000 rows can crawl with 10 million. The classic culprits are missing indexes, queries that fetch far more data than the page needs, and filtering or sorting on unindexed columns.
Before touching any code, find your slowest queries and check their EXPLAIN plans. An index added in the right place is often the cheapest performance win you'll ever get.
2. N+1 queries: the classic Rails trap
ActiveRecord makes it very easy to write code that looks innocent but fires one query per record. Render a list of 50 posts and call post.author.name in the view, and you've just run 51 queries instead of 2. It works fine in development with seed data, then quietly multiplies in production.
The fix is usually a well-placed includes or preload — the hard part is knowing the N+1 exists at all, because each individual query is fast and nothing errors.
3. Doing too much work inside the request
Calling external APIs, sending emails, generating PDFs, resizing images — anything slow that happens during the request cycle makes the user wait for it. A payment provider having a bad day shouldn't turn your checkout page into a 20-second spinner.
The rule of thumb: if the user doesn't need the result on this page load, move it to a background job.
4. Background jobs quietly piling up
Speaking of jobs — they hide problems well, because no user is staring at them. Queues back up, jobs retry thousands of times, and a "quick" job that got 500ms slower starts costing real money at scale. If emails arrive late or data seems stale, check your queue latency before blaming the code.
5. Little or no caching
Rails ships with excellent caching tools — fragment caching, low-level caching with Rails.cache, HTTP caching — and plenty of apps use none of them. You don't need to cache everything. Recomputing the same expensive thing on every request, for every user, is where the easy wins are: think dashboards, counts, and rendered partials that rarely change.
6. Memory bloat and bloated responses
Loading 100,000 ActiveRecord objects into memory to iterate over them will slow the request, balloon your memory, and give the garbage collector a workout. Watch for unbounded .all calls, giant JSON serializations, and memory that only ever grows until the process restarts. find_each, pagination, and selecting only the columns you need go a long way.
7. Slow views and the frontend
Sometimes the server responds quickly and the app still feels slow. Heavy partials rendered in loops, oversized images, and megabytes of JavaScript all count toward what the user actually experiences. Server timing is only half the story.
You can't fix what you can't see
Notice the pattern: almost every item above is invisible in development and only shows up under production data and traffic. Guessing doesn't work — measuring does.
That's exactly why we built DeadBro, an APM made specifically for Rails. It flags N+1 queries in real time with the exact line numbers that caused them, shows your slowest SQL with optional EXPLAIN plans, and puts request traces, errors, memory patterns, and uptime checks in one dashboard. Setup is a gem, an initializer, and an API key — about 5 minutes — and the free tier stays free, with pricing based on requests rather than servers.
Where to start
Don't try to fix everything at once. Get visibility first, find your slowest endpoint, and work down the list: check for N+1s, check the SQL, move slow work to jobs, cache what rarely changes. Most "slow Rails app" stories end with two or three targeted fixes — not a rewrite.
Your Rails app is trying to tell you something. Start listening.