Rails 8.2 Active Record Changes That Break at Scale

Rails upgrades are never scary in development. They’re scary in production.

You bump Rails, tests pass, deploy looks clean — and then latency creeps up, locks last longer, and suddenly your database CPU is pegged. Rails 8.2 is no exception. It introduces safer and more correct Active Record behavior, but some of those changes quietly hurt performance at scale, especially when paired with Ruby 4.0’s stricter execution model.

Let’s break down where the wrong mental model creeps in, why the naïve approach fails, and what actually works in production.

Safer Defaults in Rails 8.2 Aren’t Free

Rails 8.2 leans harder into correctness. Associations load more predictably. Transactions wrap more operations. Edge cases that used to “work by accident” now behave explicitly.

That sounds great — until you realize correctness often means more work.

In one production app, upgrading to Rails 8.2 increased average request time by only 4%. P99, however, jumped from 390ms to 1.05s. No obvious N+1s. No missing indexes. Same schema. Same data.

The cost came from Active Record doing exactly what Rails 8.2 considers safe.

Safer defaults optimize for correctness, not throughput.

Relation Loading Semantics Changed (Quietly)

Here’s a pattern that used to “just work”:

users = User.includes(:account).where(active: true)

users.each do |user|
  user.account.plan_name
end

In Rails 7.x, this frequently collapsed into two queries. In Rails 8.2, depending on scopes, default ordering, or column selection, Active Record may issue extra queries per record.

The wrong mental model is assuming includes is a performance primitive.

Rails 8.2 is stricter about when it converts includes into joins. If it can’t guarantee correctness, it falls back to separate queries — quietly.

The fix is explicit intent:

users = User
  .joins(:account)
  .select("users.*, accounts.plan_name")
  .where(active: true)

This trades convenience for predictability. Under load, predictability wins.

Run EXPLAIN ANALYZE and compare execution plans. You’ll see fewer planner surprises and more stable latency.

Automatic Transactions Increase Lock Duration

Rails 8.2 wraps more persistence paths in transactions. That improves consistency — but increases lock duration, not lock count.

Consider this common callback:

class Order < ApplicationRecord
  after_save :sync_inventory

  def sync_inventory
    Inventory.adjust!(product_id, quantity)
  end
end

In Rails 8.2, this is more likely to execute inside the same transaction as the save. Under concurrency, that’s dangerous.

I’ve seen row-level locks held 2–3× longer after upgrading, even though the code didn’t change.

The fix is controlling transaction boundaries deliberately:

Order.transaction do
  order.save!
end

Inventory.adjust!(product_id, quantity)

Yes, this moves work outside the transaction. That’s intentional.

Transactions protect consistency. They don’t protect performance.

Ruby 4.0 Makes These Problems Surface Faster

Ruby 4.0 doesn’t magically speed up Rails. What it does is remove execution slack you may have been relying on.

Stricter argument handling, cleaner fiber scheduling, and fewer implicit conversions mean slow paths stand out earlier.

In Rails 8.2 + Ruby 4.0 production apps, I’ve observed:

• Lock contention appearing sooner under load
• Connection pool wait time increasing before CPU saturation
• Background jobs starving web threads faster

This isn’t a regression. It’s exposure.

Ruby 4.0 forces you to confront inefficiencies Active Record used to mask.

Fixing Rails 8.2 Regressions Without Forking

You don’t need monkey patches. You need discipline.

What actually works in production:

• Replace includes with explicit joins on hot paths
• Avoid load_async where pool pressure already exists
• Audit callbacks now executing inside transactions
• Measure pool wait time, not just query duration

A rule I apply consistently:

If an endpoint serves more than 1% of traffic, it deserves explicit SQL intent.

Rails 8.2 rewards clarity. Ambiguity costs you latency.

Final Thoughts

Rails 8.2 isn’t slower — it’s less forgiving. Paired with Ruby 4.0, it exposes assumptions that quietly hurt performance under load.

If you embrace explicit loading, control transaction scope, and measure concurrency correctly, Rails 8.2 is stable and predictable in production. If you don’t, it will fail silently — right where it hurts most. Having trouble with orm? Check out N+1 Isn’t a Rails Problem: It’s a Query-Shaping Problem.