Optimizing Django ORM Queries: A Practical Guide to select_related and prefetch_related

Heitor Vasconcelos — Mon, 22 Jun 2026 00:02:49 +0000

1. Introduction

Django's ORM is one of its greatest strengths. It abstracts away raw SQL, lets you express database operations in clean Python, and gets you productive fast. But that convenience comes with a hidden cost: if you're not deliberate about how you fetch related objects, you'll silently generate far more queries than you intend — and you won't notice until your app slows to a crawl in production.

The most common culprit is the N+1 query problem: a pattern where fetching a list of N objects triggers an additional query for each one, resulting in N+1 total round-trips to the database. At ten rows it's invisible. At ten thousand rows, it's a disaster.

Django provides two tools to fix this: select_related and prefetch_related. This article explains how each one works internally, when to use which, and how to combine them effectively — with before/after examples and real query counts throughout.

2. Understanding the N+1 Problem

Consider a simple blog with posts and authors. You want to render a list of posts, showing each post's title and its author's name.

Models:

# models.py
from django.db import models


class Author(models.Model):
    name: str = models.CharField(max_length=100)


class Post(models.Model):
    title: "str = models.CharField(max_length=200)"
    author: Author = models.ForeignKey(
        Author,
        on_delete=models.CASCADE,
        related_name="posts",
    )

The naive approach:

# views.py
from django.db import connection
from .models import Post


def list_posts() -> None:
    posts = Post.objects.all()  # Query 1: fetch all posts

    for post in posts:
        print(f"{post.title} by {post.author.name}")
        # ^^^ Query 2, 3, 4, ... N+1: one per post

For 100 posts, this produces 101 queries. Django lazily fetches post.author the first time you access it on each object. Each access hits the database separately.

You can verify this with django.db.connection.queries (requires DEBUG = True):

from django.db import connection, reset_queries

reset_queries()
posts = Post.objects.all()
for post in posts:
    _ = post.author.name

print(len(connection.queries))  # 101

In development, django-debug-toolbar gives you a visual breakdown of every query and its duration — highly recommended for catching this early.

3. `select_related` — For ForeignKey and OneToOne

How it works

select_related performs a SQL JOIN and retrieves the related object's data in a single query. When you access post.author, Django reads from the already-fetched data in memory — no additional database hit.

-- What Django generates under the hood:
SELECT post.id, post.title, post.author_id,
       author.id, author.name
FROM blog_post post
INNER JOIN blog_author author ON (post.author_id = author.id);

When to use it

Use select_related for:

ForeignKey relationships
OneToOneField relationships

These are the cases where the related object lives in a separate table and is reachable via a direct JOIN — exactly what select_related is built for.

Before / after

Before (101 queries for 100 posts):

def list_posts_naive() -> None:
    posts = Post.objects.all()
    for post in posts:
        print(f"{post.title} by {post.author.name}")

After (1 query):

def list_posts_optimized() -> None:
    posts = Post.objects.select_related("author")
    for post in posts:
        print(f"{post.title} by {post.author.name}")

You can also traverse multiple levels of ForeignKey in one call:

# Fetches post → author → country in a single JOIN
posts = Post.objects.select_related("author__country")

Limitations

select_related does not work for ManyToManyField or reverse ForeignKey (one-to-many) relationships. A JOIN on those would multiply rows rather than resolve them cleanly. For those cases, use prefetch_related.

4. `prefetch_related` — For ManyToMany and Reverse FK

How it works

prefetch_related takes a different approach: it runs separate queries for each relationship and then merges the results in Python. For a queryset of posts with tags (ManyToMany), Django will:

Fetch all posts — 1 query.
Fetch all tags for those posts in one WHERE id IN (...) query — 1 query.
Map tags back to their posts in memory.

Total: 2 queries, regardless of how many posts or tags you have.

When to use it

Use prefetch_related for:

ManyToManyField relationships
Reverse ForeignKey lookups (e.g., fetching all comments for each post)

Before / after

Models:

class Tag(models.Model):
    name: str = models.CharField(max_length=50)


class Post(models.Model):
    title: str = models.CharField(max_length=200)
    author: Author = models.ForeignKey(Author, on_delete=models.CASCADE)
    tags: models.ManyToManyField = models.ManyToManyField(Tag, related_name="posts")

Before (1 + N queries):

def list_posts_with_tags_naive() -> None:
    posts = Post.objects.all()
    for post in posts:
        tag_names = [tag.name for tag in post.tags.all()]
        print(f"{post.title}: {', '.join(tag_names)}")

After (2 queries):

def list_posts_with_tags_optimized() -> None:
    posts = Post.objects.prefetch_related("tags")
    for post in posts:
        tag_names = [tag.name for tag in post.tags.all()]
        print(f"{post.title}: {', '.join(tag_names)}")

The `Prefetch` object

For finer control — filtering, ordering, or annotating the prefetched queryset — use the Prefetch class:

from django.db.models import Prefetch
from .models import Post, Tag


def list_posts_active_tags() -> None:
    active_tags = Tag.objects.filter(active=True).order_by("name")

    posts = Post.objects.prefetch_related(
        Prefetch("tags", queryset=active_tags, to_attr="active_tags")
    )

    for post in posts:
        # post.active_tags is a plain list, not a queryset
        tag_names = [tag.name for tag in post.active_tags]
        print(f"{post.title}: {', '.join(tag_names)}")

to_attr stores the prefetched result as a Python list on the object, which is slightly faster to access than a queryset and makes the code intent explicit.

5. Combining Both

Real-world models rarely have just one relationship. Here's a more realistic example — a Post that has an Author (ForeignKey) and Tags (ManyToMany):

from django.db.models import Prefetch
from .models import Post, Tag


def list_posts_full() -> None:
    posts = (
        Post.objects
        .select_related("author")          # JOIN for ForeignKey
        .prefetch_related(                  # Separate query for ManyToMany
            Prefetch(
                "tags",
                queryset=Tag.objects.only("name"),
                to_attr="tag_list",
            )
        )
    )

    for post in posts:
        tag_names = [tag.name for tag in post.tag_list]
        print(f"{post.title} by {post.author.name} — tags: {', '.join(tag_names)}")

Total queries: 2 — one for posts JOIN author, one for all tags. This stays flat no matter how many posts are in the queryset.

You can chain as many select_related and prefetch_related calls as needed. Django deduplicates and optimizes them before sending anything to the database.

6. Common Pitfalls

Using `select_related` on ManyToMany

select_related silently ignores relationships it can't JOIN cleanly. You won't get an error — you'll just get the N+1 behavior back, with no warning.

# ❌ Does nothing for ManyToMany — falls back to per-object queries
posts = Post.objects.select_related("tags")

# ✅ Correct
posts = Post.objects.prefetch_related("tags")

Filtering a prefetched queryset after the fact

Prefetching caches the queryset result. If you apply a filter after the fact on a prefetched relation, Django bypasses the cache and hits the database again:

posts = Post.objects.prefetch_related("tags")

for post in posts:
    # ❌ New query per post — cache is bypassed
    active = post.tags.filter(active=True)

    # ✅ Filter inside the Prefetch object instead

The fix is to push the filter into a Prefetch object as shown in section 4.

Over-fetching with `select_related`

A wide JOIN can pull in more data than you need. If you only use post.author.name, fetching the entire Author row (with bio, avatar URL, created_at, etc.) wastes bandwidth. Combine with only() to limit columns:

posts = Post.objects.select_related("author").only(
    "title", "author__name"
)

7. Conclusion

The choice between select_related and prefetch_related comes down to the relationship type:

Relationship	Tool
`ForeignKey` / `OneToOneField`	`select_related` (SQL JOIN)
`ManyToManyField` / Reverse FK	`prefetch_related` (separate queries + Python merge)
Both in the same queryset	Chain them together

Start by identifying your hot querysets — the ones called on list pages or inside loops. Add django-debug-toolbar to your dev environment and look for duplicate queries. Then apply select_related or prefetch_related as appropriate and watch your query count drop.

Once you've mastered these two tools, the natural next steps are only() and defer() to control which columns are fetched, and annotate() with aggregates to push computation into the database instead of Python. Those techniques, combined with what you've learned here, cover the vast majority of Django ORM performance problems you'll encounter in production.

DEV Community: Heitor Vasconcelos

Optimizing Django ORM Queries: A Practical Guide to select_related and prefetch_related

1. Introduction

2. Understanding the N+1 Problem

3. select_related — For ForeignKey and OneToOne

How it works

When to use it

Before / after

Limitations

4. prefetch_related — For ManyToMany and Reverse FK

How it works

When to use it

Before / after

The Prefetch object

5. Combining Both

6. Common Pitfalls

Using select_related on ManyToMany

Filtering a prefetched queryset after the fact

Over-fetching with select_related

7. Conclusion

3. `select_related` — For ForeignKey and OneToOne

4. `prefetch_related` — For ManyToMany and Reverse FK

The `Prefetch` object

Using `select_related` on ManyToMany

Over-fetching with `select_related`