When investigating a slow Rails endpoint, it's common to start by looking for N+1 queries, missing indexes, or expensive joins. Sometimes, though, the real culprit is much smaller.
It might be hiding in a method call you've written hundreds of times without thinking about it.
In Rails, .count, .length, and .size all return a number, and many developers use them interchangeably. Under the hood, however, they behave very differently.
Let's break down how each method works and see which one is the right choice for different situations.
.count: Always Hits the Database
.count runs a SQL COUNT(*) query every single time you call it:
post.comments.count
# SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1
This is great when you only need a number and don't need the records themselves. The database does the counting and returns a single integer, without loading any records into memory.
But there's a catch that surprises people.
.count ignores records that are already loaded. Even if you've just pulled the whole association into memory, calling .count fires another query:
post.comments.load
# Loads objects into memory
post.comments.count
# SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1
This means repeated calls to .count can generate unnecessary database queries, even when the records are already loaded.
.length: Always Counts in Memory
Unlike .count, .length doesn't ask the database for a count.
If the association has not been loaded yet, Rails first loads every matching record into memory, with all of its columns, and only then counts them:
post.comments.length
# SELECT "comments".* FROM "comments" WHERE "comments"."post_id" = 1
That means a simple call to .length on a post with 10,000 comments will instantiate 10,000 Comment objects just to return a number.
On the other hand, .length shines when the association has already been loaded:
post.comments.load
# Loads objects into memory
post.comments.length
# => 10000
No additional query is executed. Rails simply counts the records already in memory.
In other words, .length behaves like an Array. If the records are already there, it's free. If they aren't, Rails has to load them all first.
.size: The Adaptive One
.size combines the best parts of .count and .length.
If the association has not been loaded yet, .size behaves like .count and executes a lightweight COUNT(*) query:
post.comments.size
# SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1
But once the association has already been loaded, .size behaves like .length and simply counts the records already in memory:
post.comments.load
# Loads objects into memory
post.comments.size
# => 10000
No additional query is executed.
In short, .size adapts to the association's current state, avoiding both unnecessary record loading and redundant COUNT(*) queries.
That's why .size is often the best default choice.
Bonus: .size and Counter Cache
If a counter_cache is set up, .size can skip the database entirely:
class Comment < ApplicationRecord
belongs_to :post, counter_cache: true
end
Rails now keeps a comments_count column on posts table, and .size reads it directly. No COUNT(*), no records loaded:
post.comments.size
# => 10000 (reads post.comments_count)
A Rule of Thumb
- Use
.countwhen you always want the latest value from the database. - Use
.lengthwhen you've already loaded the records and just need to count them in memory. - Use
.sizewhen you want Rails to choose the most efficient option automatically.
And if you remember just one thing: in most cases, .size is the safest default, because it adapts to the current state of the association.
This is part of a small series on subtle ActiveRecord behaviors that quietly affect performance. The first post covered .any? vs .exists? and the same kind of hidden cost.