The N+1 query problem is the most common Django ORM performance issue: accessing related objects in a loop triggers a separate database query for each one. select_related and prefetch_related solve it by fetching related data efficiently — they're essential optimization tools.
books = Book.objects.()
book books:
(book.author.name)
Each book.author access lazily queries the database again. With 100 books, that's 101 queries — a severe, sneaky performance killer that often only surfaces under real data volumes.
# ✅ ONE query with a JOIN
books = Book.objects.select_related("author").all()
for book in books:
print(book.author.name) # NO extra queries — author was JOINed in
# 100 books → 1 query total
select_related performs a SQL JOIN to fetch the related object(s) in the same query. Use it for forward ForeignKey and OneToOne relationships (single related object), where a JOIN is efficient.
# ✅ TWO queries total (not N+1)
authors = Author.objects.prefetch_related("books").all()
for author in authors:
for book in author.books.all(): # NO extra queries — books were prefetched
print(book.title)
# query 1: all authors; query 2: all their books → Django joins them in Python
prefetch_related runs a separate query for the related objects and joins them in Python. Use it for ManyToMany and reverse ForeignKey relationships (multiple related objects), where a JOIN would multiply rows inefficiently.
select_related → ForeignKey, OneToOne (forward, single object) → SQL JOIN, 1 query
prefetch_related → ManyToMany, reverse ForeignKey (many objects) → 2 queries, joined in Python
You can combine and chain them, and span relationships:
Book.objects.select_related("author").prefetch_related("tags")
Book.objects.select_related("author__publisher") # multi-level
✓ Django Debug Toolbar — shows the query count per page (spot N+1 visually)
✓ django-silk, or logging queries (connection.queries) to count them
→ If a page runs hundreds of similar queries, you likely have an N+1.
The N+1 query problem is the single most common and impactful performance issue in Django applications, and understanding select_related/prefetch_related is essential for writing performant code.
The problem is insidious because the convenient ORM syntax that makes accessing related objects so easy (book.author.name) silently triggers a database query each time — code that works fine with a few records degrades catastrophically with real data volumes (100 records → 101 queries), often only discovered in production under load.
These two tools are the standard, essential solution: select_related uses a SQL JOIN to fetch forward ForeignKey/OneToOne relationships in a single query, while prefetch_related uses a separate query (joined in Python) for ManyToMany/reverse-ForeignKey relationships where a JOIN would be inefficient — and knowing which to use for which relationship type is the key skill.
Mastering them turns hundreds of queries into one or two, often improving page performance dramatically.
This optimization is so fundamental that recognizing N+1 problems (using tools like Django Debug Toolbar to spot excessive query counts) and applying the right fix is a core competency that distinguishes developers who write efficient Django code from those whose apps slow to a crawl as data grows.
It's also among the most frequently-tested Django interview topics, precisely because it reflects practical, performance-critical ORM understanding.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate