Rails includes vs joins: Understanding Eager Loading and SQL Joins in ActiveRecord

By the end of this page, you will understand how Rails includes and joins serve different purposes. You will learn that includes is mainly for eager loading associations to prevent N+1 queries, while joins is mainly for combining tables in SQL for filtering or matching rows. You will also see why includes often uses separate queries, when it may switch to a join-like query, and how to choose the right tool in real applications.

includes and joins are related, but they solve different problems.

includes: load associated records efficiently

The main job of includes is eager loading. That means Rails loads the parent records and their associated records ahead of time so that later access does not trigger one query per record.

Without eager loading:

posts = Post.all
posts.each do |post|
  puts post.comments.size
end

This can cause an N+1 query problem:

• 1 query to load posts
• 1 query per post to load comments

With eager loading:

posts = Post.includes(:comments)

Rails can load:

• posts in one query
• all comments for those posts in one additional query

That is still eager loading, even though it is not a single SQL join.

joins: combine tables in SQL

The main job of joins is to tell the database to combine rows from multiple tables in one SQL statement.

Think of includes and joins as two different ways of preparing for a meeting.

includes is like sending two organized lists

Imagine you need a list of posts and their comments.

Instead of writing one giant document where each post is repeated for every comment, you send:

• one list of posts
• one list of comments grouped by post ID

That is what Rails often does with includes.

It is tidy and avoids repeating the same post data over and over.

joins is like merging everything into one spreadsheet

Now imagine you need one table where each row combines post and comment data together.

That is what a SQL join does.

It is useful for searching, filtering, and sorting across both tables, but it can repeat post data many times.

Easy rule to remember

• Use includes when you plan to access associated objects
• Use joins when you need to query through associated tables

Basic syntax

Eager load associations

Post.includes(:comments)

Join associated tables

Post.joins(:comments)

Eager load multiple associations

Post.includes(:comments, :author, :category)

Join nested associations

Post.joins(comments: :user)

Example: includes

posts = Post.includes(:comments)

posts.each do |post|
  puts "#{post.title}: #{post.comments.count} comments"
end

What happens

Rails typically does:

Consider this code:

posts = Post.includes(:comments)

posts.each do |post|
  puts post.comments.map(&:body)
end

Step 1: Load posts

Rails first loads all posts:

SELECT * FROM posts;

Suppose it gets these IDs:

• 1
• 2
• 3

Step 2: Load comments for all loaded posts

Rails then loads all related comments in one query:

SELECT * FROM comments WHERE post_id IN (1, 2, 3);

Step 3: Match comments to posts in memory

Rails groups comments by post_id.

• comments with post_id = 1 belong to post 1
• comments with post_id = 2 belong to post 2

1. Rendering pages with associated data

If a page shows posts, authors, and comments, includes helps load everything needed for display without many repeated queries.

Post.includes(:author, :comments)

2. Filtering records by association data

If you want posts that have approved comments, joins is a natural fit.

Post.joins(:comments).where(comments: { approved: true })

3. Admin dashboards

Dashboards often list objects plus related counts or details. includes helps avoid query explosions when rendering tables.

4. Reporting and search

Search screens often need SQL conditions across related tables. joins is useful for combining tables in one query.

5. API endpoints

When serializing nested data in JSON, includes can reduce database round trips.

Post.includes(:comments, )

In real Rails applications, developers often combine these tools carefully.

Common pattern: eager load for views and serializers

@posts = Post.includes(:author, :comments).recent

This is common in controllers, API endpoints, and background jobs that read associations.

Common pattern: join for filtering, includes for later access

@posts = Post.joins(:comments)
             .where(comments: { approved: true })
             .includes(:comments)
             .distinct

Why this pattern is useful:

• joins filters posts using the comments table
• includes preloads comments for later use
• distinct avoids duplicate posts caused by joins

Guarding against N+1 in views

A team may notice this in a template:

@posts.each do |post|
  post.comments.each do |comment|
    
  

Mistake 1: Assuming includes always means one SQL join

Broken expectation:

Post.includes(:comments)

Many beginners expect a single JOIN query every time. But includes often uses separate queries for eager loading.

How to avoid it

Remember:

• includes means preload associations
• it does not guarantee one joined SQL statement

Mistake 2: Using joins and expecting associations to be preloaded

Broken code:

posts = Post.joins(:comments)
posts.each do |post|
  puts post.comments.size
end

Problem:

• joins helps build the SQL query
• later calls to post.comments may still trigger extra queries

How to avoid it

If you need both filtering and preloading, combine them:

# Eager load association
Post.includes(:comments)

# Join association
Post.joins(:comments)

# Filter by associated table
Post.joins(:comments).where(comments: { approved: true })

# Filter and also preload
Post.joins(:comments).where(comments: { approved: true }).includes(:comments).distinct

Key rules

• includes is for eager loading
• joins is for SQL joins
• includes often uses 2 queries, not 1 join
• joins does not automatically preload associations
• joins can create duplicate parent rows
• use distinct when needed with joins
• conditions on included tables can make Rails use join-like SQL

Watch for

• N+1 queries in loops
• duplicate rows from joins
• assuming eager loading and SQL joining are the same thing

Does includes always generate a SQL join in Rails?

No. includes often uses separate queries: one for the parent records and one for the associated records.

Why does Rails use two queries for includes?

Because eager loading with separate queries often avoids duplicated parent rows and can be more efficient for loading associations.

When does includes use a join?

When the query needs the associated table for conditions, ordering, or references, Rails may switch to a join-like strategy.

What is the main difference between includes and joins?

includes is for eager loading associations. joins is for combining tables in SQL.

Can joins cause N+1 queries?

Yes. If you use joins and later access the association objects, Rails may still issue additional queries.

Why do joined queries sometimes look slower?

Joined queries may return more duplicated data and require more work from the database. One query is not always faster than two smaller ones.

Should I always prefer includes over ?

• N+1 queries — This is the main performance problem includes helps solve.
• Eager loading — includes is a form of eager loading in ActiveRecord.
• Lazy loading — Associations normally load only when accessed.
• Inner join — joins commonly produces an SQL INNER JOIN.
• Left outer join — Rails may use this when eager loading and preserving parent rows.
• ActiveRecord associations — Understanding has_many and belongs_to makes includes and joins clearer.
• preload — A more explicit eager loading strategy that uses separate queries.
• eager_load — A more explicit eager loading strategy that uses a join-based approach.
• distinct — Useful for removing duplicate parent rows caused by joins.