Learning Django QuerySet internals – Understand lazy evaluation and caching

When working with Django, you interact with the database primarily through QuerySets. Whether you're retrieving a single record, filtering data, or aggregating results, QuerySets are the foundation of Django's Object-Relational Mapping (ORM) system.

Most developers know how to use QuerySets, but fewer understand how they work internally. One of Django ORM's most powerful features is lazy evaluation, which delays database access until the data is actually needed. Combined with QuerySet caching, this behavior helps Django applications remain efficient and scalable.

In this tutorial, you'll learn:

What a QuerySet really is
How lazy evaluation works
When database queries are executed
How QuerySet caching improves performance
Common mistakes that cause unnecessary queries
Best practices for optimizing Django ORM performance

By the end of this guide, you'll have a deeper understanding of Django's ORM internals and be able to write more efficient database code.

Prerequisites

To follow this tutorial, you should have:

Python 3.10 or later installed
Django 5.x installed
Basic knowledge of Django models and ORM
A Django project for experimentation

You can verify your Django version:

python -m django --version

If the message shows like this:

/usr/local/bin/python3: No module named django

Install the latest Django.

python -m pip install Django

For demonstration purposes, we'll use a simple Book model:

from django.db import models

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.CharField(max_length=100)
    published = models.BooleanField(default=True)
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

Open the Django shell:

python manage.py shell

All examples in this tutorial can be tested directly from the shell.

What Is a Django QuerySet?

A QuerySet represents a collection of database records retrieved from your Django models. You can think of it as a database query builder that allows you to construct SQL queries using Python code.

For example:

books = Book.objects.all()

At first glance, this may seem like it immediately retrieves all books from the database. However, Django behaves differently.

The variable books does not contain actual database records yet. Instead, it contains a QuerySet object that describes how the data should be retrieved.

Let's inspect it:

type(books)

Output:

<class 'django.db.models.query.QuerySet'>

A QuerySet acts like a recipe for a database query rather than the query result itself.

You can continue modifying it:

books = Book.objects.filter(published=True)

Or chain multiple operations:

books = (
    Book.objects
    .filter(published=True)
    .order_by('-created_at')
)

Still, no database query has been executed.

This behavior is possible because QuerySets are lazy.

Understanding Lazy Evaluation

Lazy evaluation is one of Django ORM's most important optimization techniques.

Instead of executing SQL immediately, Django waits until the application actually needs the data.

Consider this example:

books = Book.objects.filter(published=True)

print("Query created")

Output:

Query created

No database query is executed.

The QuerySet simply stores information about:

The model being queried
Filters applied
Ordering instructions
Other query conditions

Internally, Django builds a query object but postpones SQL generation and execution.

This allows multiple operations to be combined efficiently before the final SQL statement is sent to the database.

For example:

books = (
    Book.objects
    .filter(published=True)
    .exclude(author="Anonymous")
    .order_by("-created_at")
)

Django stores all these instructions and combines them into a single SQL query later.

Why Lazy Evaluation Matters

Without lazy evaluation, each operation could generate a separate SQL query.

Imagine:

Book.objects.filter(published=True)
Book.objects.exclude(author="Anonymous")
Book.objects.order_by("-created_at")

If each operation were executed immediately, database traffic would increase significantly.

Instead, Django waits and generates a single optimized query.

This design:

Reduces database load
Improves application performance
Minimizes network traffic
Allows flexible query composition

When Does a QuerySet Actually Execute?

A QuerySet remains unevaluated until Django needs actual data.

Let's create a QuerySet:

books = Book.objects.filter(published=True)

At this point, no SQL query has been executed.

The query executes when you iterate through the results:

for book in books:
    print(book.title)

Now Django sends SQL to the database and retrieves matching rows.

Common Evaluation Triggers

Iteration

for book in books:
    print(book.title)

Database query executes immediately.

Converting to a List

book_list = list(books)

Django must retrieve all rows to create the list.

Using len()

len(books)

To determine the length, Django first fetches all matching records.

Boolean Evaluation

if books:
    print("Books exist")

Django evaluates the QuerySet to determine whether records exist.

Accessing an Item by Index

first_book = books[0]

Django executes a query with a database limit.

Calling first()

book = books.first()

Retrieves the first matching record.

Aggregations

books.count()

Django immediately executes:

SELECT COUNT(*)

because the count value is needed immediately.

Viewing the SQL Generated by Django

One of the best ways to understand QuerySet internals is to inspect the generated SQL.

Create a QuerySet:

books = Book.objects.filter(
    published=True
).order_by("-created_at")

Display the SQL:

print(books.query)

Example output:

SELECT
    "books_book"."id",
    "books_book"."title",
    "books_book"."author",
    "books_book"."published",
    "books_book"."created_at"
FROM "books_book"
WHERE "books_book"."published" = TRUE
ORDER BY "books_book"."created_at" DESC

Notice something interesting:

The SQL can be generated and displayed without actually retrieving records.

Django's query construction and query execution are separate processes.

This separation is a key reason why lazy evaluation works so effectively.

QuerySet Chaining and Immutability

Another important internal concept is that QuerySets are immutable.

Each operation creates a new QuerySet instead of modifying the existing one.

Consider:

qs1 = Book.objects.all()

qs2 = qs1.filter(published=True)

qs3 = qs2.order_by("-created_at")

Internally:

qs1 → all books

qs2 → published books

qs3 → published books ordered by date

The original QuerySet remains unchanged.

print(qs1.query)

Shows:

SELECT * FROM books_book

While:

print(qs3.query)

Shows the filtered and ordered version.

This immutability allows QuerySets to be safely reused throughout your application.

Understanding QuerySet Caching

One of the lesser-known but extremely useful features of Django QuerySets is result caching.

When a QuerySet is evaluated for the first time, Django stores the retrieved records in an internal cache. Subsequent access to the same QuerySet can reuse the cached data instead of sending another query to the database.

This mechanism helps reduce unnecessary database activity and improves application performance.

Let's see how it works.

First Evaluation

Create a QuerySet:

books = Book.objects.filter(published=True)

At this stage:

No SQL query has been executed
No results are cached

Now iterate through the QuerySet:

for book in books:
    print(book.title)

Django performs the following steps:

Generates SQL
Executes the query
Retrieves all matching rows
Stores results in an internal cache

The cache now contains the retrieved Book objects.

Second Evaluation Uses the Cache

Run the loop again:

for book in books:
    print(book.title)

This time:

No new SQL query is executed
Results are served from memory

The database is not contacted again because Django already has the results available.

This behavior is especially beneficial when the same QuerySet is accessed multiple times within a request.

For example:

books = Book.objects.filter(published=True)

for book in books:
    print(book.title)

print(f"Total books: {len(books)}")

Without caching, Django would need to execute two queries.

With caching:

The first loop executes the query
The cached results are reused by len()

Only one database query is needed.

Inspecting the Internal Cache

Internally, QuerySets maintain a private attribute called _result_cache.

Note: _result_cache is an internal implementation detail and should not be relied upon in production code.

Before evaluation:

books = Book.objects.filter(published=True)

print(books._result_cache)

Output:

None

No results have been fetched yet.

Now evaluate the QuerySet:

list(books)

Inspect again:

print(books._result_cache)

Output:

[
    <Book: Django for Beginners>,
    <Book: Python Tricks>,
    <Book: Effective Django>
]

The QuerySet now holds the retrieved model instances in memory.

Visualizing the QuerySet Lifecycle

The lifecycle typically looks like this:

Create QuerySet
       │
       ▼
Unevaluated QuerySet
       │
       ▼
First Evaluation
       │
       ▼
Execute SQL
       │
       ▼
Store Results in Cache
       │
       ▼
Subsequent Access Uses Cache

This is why understanding evaluation timing is important when optimizing performance.

When QuerySet Cache Is Not Reused

QuerySet caching only applies to the specific QuerySet instance.

Consider:

books = Book.objects.filter(published=True)

list(books)

The results are now cached.

Now create a new QuerySet:

python_books = books.filter(title__icontains="Python")

Even though python_books originates from books, Django creates a new QuerySet object.

When evaluated:

list(python_books)

A new SQL query is executed.

Why?

Because:

Different QuerySet
Different SQL
Different result set

The cache belongs only to the original QuerySet.

Example: Cache Not Shared Between QuerySets

qs1 = Book.objects.filter(published=True)

list(qs1)

qs2 = qs1.order_by("-created_at")

list(qs2)

Queries executed:

Fetch published books
Fetch published books ordered by creation date

Although related, these are two separate QuerySets.

Each maintains its own cache.

Understanding QuerySet Cloning

Every QuerySet operation returns a clone.

For example:

base_qs = Book.objects.all()

published_qs = base_qs.filter(published=True)

recent_qs = published_qs.order_by("-created_at")

Internally:

base_qs
    │
    ├── published_qs
            │
            └── recent_qs

Each QuerySet:

Has its own query state
Has its own cache
Can be evaluated independently

This design makes QuerySets thread-safe and highly composable.

count() vs len(): Understanding the Difference

Many Django developers unknowingly use len() when count() would be more efficient.

Let's compare them.

Using count()

Book.objects.filter(
    published=True
).count()

Generated SQL:

SELECT COUNT(*)
FROM books_book
WHERE published = TRUE;

Only a number is returned.

No model instances are loaded.

Using len()

len(
    Book.objects.filter(
        published=True
    )
)

Django must:

Execute the query
Retrieve every matching row
Create model objects
Count them in Python

This can be significantly slower when thousands of records are involved.

Performance Comparison

Imagine a table containing:

50,000 rows

Using:

Book.objects.count()

The database returns a single integer.

Using:

len(Book.objects.all())

The database returns all 50,000 rows.

Memory usage increases dramatically.

Recommendation

Use:

Book.objects.count()

when you only need the number of records.

exists() vs len() > 0

Another common mistake is checking whether records exist using len().

Bad example:

if len(books) > 0:
    print("Books found")

This loads all matching rows.

A better approach:

if books.exists():
    print("Books found")

Generated SQL:

SELECT 1
FROM books_book
WHERE published = TRUE
LIMIT 1;

The database stops after finding the first matching row.

This is much faster for large datasets.

Caching and Memory Considerations

Caching improves performance, but it also consumes memory.

Consider:

books = Book.objects.all()

list(books)

If the table contains:

100,000 rows

All 100,000 model instances are stored in memory.

This can become problematic in large applications.

Using iterator() to Disable Caching

For very large result sets, Django provides iterator().

for book in Book.objects.iterator():
    print(book.title)

Benefits:

Results streamed directly from the database
Reduced memory consumption
No QuerySet result cache created

This is ideal for:

Data migrations
Batch processing
Export scripts
Background jobs

Demonstrating Caching with Django Debug Toolbar

The easiest way to observe QuerySet caching in practice is using the Django Debug Toolbar.

Install it:

pip install django-debug-toolbar

Add it to INSTALLED_APPS:

INSTALLED_APPS = [
    ...
    "debug_toolbar",
]

Add middleware:

MIDDLEWARE = [
    ...
    "debug_toolbar.middleware.DebugToolbarMiddleware",
]

Configure URLs:

from django.urls import include, path

urlpatterns = [
    path("__debug__/", include("debug_toolbar.urls")),
]

Now browse your application and inspect:

Executed SQL statements
Duplicate queries
Query duration
Query count

This tool makes it easy to identify when QuerySets are being evaluated and whether caching is working as expected.

Avoiding N+1 Query Problems with `select_related()` and `prefetch_related()`

Understanding lazy evaluation and QuerySet caching is important, but there's another performance issue that often affects Django applications: the N+1 query problem.

The N+1 problem occurs when Django executes one query to retrieve a collection of objects and then executes additional queries for related objects.

As your database grows, this can dramatically slow down your application.

Let's see how it happens and how Django provides tools to avoid it.

What Is the N+1 Query Problem?

Suppose we have the following models:

from django.db import models

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

    def __str__(self):
        return self.name


class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(
        Author,
        on_delete=models.CASCADE
    )

    def __str__(self):
        return self.title

Now retrieve all books:

books = Book.objects.all()

Display each book's author:

for book in books:
    print(book.title, "-", book.author.name)

At first glance, this code looks harmless.

However, Django may execute:

Query 1:
Fetch all books

Query 2:
Fetch author for Book 1

Query 3:
Fetch author for Book 2

Query 4:
Fetch author for Book 3

...

If there are 100 books:

1 query for books
100 queries for authors

Total = 101 queries

This is called the N+1 query problem.

Why Does This Happen?

Remember that QuerySets are lazy.

When Django retrieves books:

books = Book.objects.all()

only the Book records are loaded.

The related Author objects are not loaded yet.

When this line executes:

book.author.name

Django notices that the related author hasn't been loaded and performs an additional query.

This process repeats for every book.

Visualizing the Problem

Without optimization:

Fetch Books
     │
     ├── Fetch Author #1
     ├── Fetch Author #2
     ├── Fetch Author #3
     ├── Fetch Author #4
     └── ...

Database traffic grows linearly with the number of records.

This can become a serious bottleneck.

Solving the Problem with `select_related()`

For one-to-one and foreign-key relationships, Django provides select_related().

Example:

books = (
    Book.objects
    .select_related("author")
)

Now iterate:

for book in books:
    print(book.title, "-", book.author.name)

Django executes a single query.

Generated SQL resembles:

SELECT
    book.id,
    book.title,
    author.id,
    author.name
FROM book
INNER JOIN author
ON book.author_id = author.id

Instead of 101 queries, Django executes only one.

How `select_related()` Works Internally

When Django builds the SQL query, it adds a database join.

Conceptually:

Books
  JOIN
Authors

The database returns all required data at once.

Django then creates:

Book object
Author object

and links them together in memory.

Subsequent access:

book.author.name

uses already-loaded data.

No additional queries are needed.

Confirming with Django Debug Toolbar

Without optimization:

101 queries

With select_related():

1 query

The difference becomes obvious in the SQL panel.

This is one of the most impactful ORM optimizations you can make.

Not all relationships can be optimized with SQL joins.

Consider:

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


class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(
        Author,
        on_delete=models.CASCADE
    )

Suppose you want all books written by each author.

Without optimization:

authors = Author.objects.all()

for author in authors:
    print(author.name)

    for book in author.book_set.all():
        print(book.title)

Django executes:

1 query for authors

1 query per author for books

If there are 50 authors:

51 queries total

Another N+1 problem.

Using `prefetch_related()`

Solution:

authors = (
    Author.objects
    .prefetch_related("book_set")
)

Now:

for author in authors:
    for book in author.book_set.all():
        print(book.title)

Django executes only:

Query 1:
Fetch authors

Query 2:
Fetch books

Total:

2 queries

regardless of the number of authors.

How `prefetch_related()` Works Internally

Unlike select_related(), Django does not use SQL joins.

Instead:

Step 1

Fetch authors:

SELECT *
FROM author;

Step 2

Fetch related books:

SELECT *
FROM book
WHERE author_id IN (...);

Step 3

Build relationships in memory.

Conceptually:

Author A
 ├── Book 1
 ├── Book 2

Author B
 ├── Book 3
 ├── Book 4

Django performs the mapping automatically.

A common interview question is:

When should I use each one?

Use `select_related()` for:

ForeignKey
OneToOneField

Example:

Book.objects.select_related("author")

Because a SQL join works efficiently.

Use `prefetch_related()` for:

ManyToManyField
Reverse ForeignKey
Complex relationships

Example:

Author.objects.prefetch_related("book_set")

Because joins could generate duplicate rows and excessive data.

Quick Comparison

Feature	select_related()	prefetch_related()
Query count	1	2 or more
Uses SQL JOIN	Yes	No
Uses Python mapping	No	Yes
ForeignKey	Excellent	Works
OneToOne	Excellent	Works
ManyToMany	Not supported	Recommended
Reverse FK	Not supported	Recommended

Combining Both Techniques

In real applications, it's common to use both.

Example:

books = (
    Book.objects
    .select_related("author")
    .prefetch_related("categories")
)

Django will:

Join the author table
Fetch categories separately
Build all relationships efficiently

This minimizes query count while avoiding large JOIN explosions.

Common Mistakes

Accessing Related Objects Inside Loops

Bad:

for book in Book.objects.all():
    print(book.author.name)

Potentially generates many queries.

Forgetting About Reverse Relationships

Bad:

for author in Author.objects.all():
    print(author.book_set.count())

May trigger a query for each author.

Overusing Prefetching

Bad:

Book.objects.prefetch_related(
    "author",
    "categories",
    "publisher",
    "reviews",
    "comments",
    "tags"
)

You may load large amounts of unused data.

Optimize only what is actually accessed.

Best Practices for Related Data Loading

Use select_related() for ForeignKey and OneToOne relationships.
Use prefetch_related() for ManyToMany and reverse relationships.
Verify optimizations using Django Debug Toolbar.
Avoid accessing related objects inside loops without prefetching.
Measure query counts during development.
Optimize only after identifying actual bottlenecks.

QuerySet Internals Recap

At this point, we've learned that:

QuerySets are lazy.
Queries execute only when evaluation occurs.
Results are cached after evaluation.
Each QuerySet maintains its own cache.
Related objects can trigger additional queries.
select_related() and prefetch_related() help eliminate N+1 problems.

Understanding these behaviors allows you to reason about database performance and write Django applications that scale efficiently.

Common QuerySet Pitfalls and Performance Best Practices

Now that we've explored lazy evaluation, caching, and relationship optimization, let's review some common mistakes developers make when working with QuerySets and how to avoid them.

Pitfall 1: Evaluating QuerySets Too Early

A common mistake is converting a QuerySet into a list before all filtering and processing are complete.

Bad example:

books = list(Book.objects.all())

python_books = [
    book for book in books
    if "Python" in book.title
]

In this case, Django loads every book into memory before filtering.

A better approach is to let the database perform the filtering:

books = Book.objects.filter(
    title__icontains="Python"
)

This generates SQL that returns only the required rows.

Best Practice

Keep QuerySets lazy as long as possible and allow the database to do the heavy lifting.

Pitfall 2: Using `len()` for Record Counts

Many developers write:

len(Book.objects.filter(published=True))

This forces Django to retrieve all matching rows before counting them.

A more efficient solution is:

Book.objects.filter(
    published=True
).count()

The database performs the counting operation and returns only a single integer.

Best Practice

Use:

.count()

whenever you only need the number of records.

Pitfall 3: Using `len()` or Boolean Checks for Existence

Consider:

if len(books) > 0:
    print("Books exist")

or:

if books:
    print("Books exist")

Both approaches may require loading records unnecessarily.

A better solution is:

if books.exists():
    print("Books exist")

This generates an optimized query that stops after finding the first matching row.

Best Practice

Use:

.exists()

for existence checks.

Pitfall 4: Triggering N+1 Queries

Consider:

for book in Book.objects.all():
    print(book.author.name)

Without optimization, Django may execute a separate query for each author.

Instead:

books = (
    Book.objects
    .select_related("author")
)

for book in books:
    print(book.author.name)

Best Practice

Always review loops that access related objects and consider using:

select_related()
prefetch_related()

when appropriate.

Pitfall 5: Loading Large QuerySets into Memory

This can become problematic:

books = list(Book.objects.all())

For a table containing thousands of records, memory usage can increase significantly.

For large datasets, use:

for book in Book.objects.iterator():
    process(book)

The records are streamed from the database instead of being fully cached.

Best Practice

Use iterator() for:

Data migrations
Batch processing
Export scripts
Background jobs

Pitfall 6: Repeating Similar Queries

Bad:

Book.objects.filter(
    published=True
).count()

Book.objects.filter(
    published=True
).first()

Book.objects.filter(
    published=True
).exists()

Each line creates and executes a separate query.

A more maintainable approach is:

published_books = Book.objects.filter(
    published=True
)

Reuse the QuerySet when appropriate.

Best Practice

Store frequently used QuerySets in variables and reuse them within the same scope.

Performance Optimization Checklist

Before deploying a Django application, consider the following checklist:

Query Construction

Keep QuerySets lazy whenever possible.
Apply filtering in the database instead of Python.
Chain QuerySet methods freely without worrying about immediate execution.

Counting and Existence Checks

Use .count() instead of len().
Use .exists() instead of a Boolean evaluation.

Related Objects

Use select_related() for ForeignKey and OneToOneField.
Use prefetch_related() for ManyToManyField and reverse relationships.

Large Datasets

Use .iterator() when processing large numbers of rows.
Avoid converting large QuerySets to lists.

Debugging

Inspect generated SQL with:

print(queryset.query)

Use Django Debug Toolbar to monitor:
- Query count
- Duplicate queries
- Query execution time

Conclusion

Django QuerySets are far more sophisticated than simple database queries. They are designed around the concepts of lazy evaluation, query composition, and result caching, allowing developers to build complex database operations efficiently.

Throughout this tutorial, you've learned that:

QuerySets do not immediately execute SQL.
Django delays database access until data is actually needed.
Evaluated QuerySets store results in an internal cache.
Each QuerySet instance maintains its own cache and query state.
Operations such as len(), list(), iteration, and indexing trigger evaluation.
Using count() and exists() often provides better performance than loading full result sets.
The N+1 query problem can severely impact performance if related objects are not loaded efficiently.
select_related() and prefetch_related() help minimize database queries and improve scalability.
Tools like Django Debug Toolbar make it easier to visualize and optimize QuerySet behavior.

Understanding these internals helps you move beyond simply using Django's ORM and enables you to make informed decisions about performance, memory usage, and database efficiency. As your applications grow, this knowledge becomes increasingly valuable for diagnosing slow queries, reducing database load, and building scalable Django systems.

The next time you write a QuerySet, remember that what looks like a simple Python expression may represent a carefully optimized database operation waiting to be executed. Mastering how and when that execution occurs is one of the key skills that separates intermediate Django developers from advanced Django practitioners.

The complete source code for this tutorial is available on the Djamware GitHub repository. Feel free to clone it, experiment with the examples, and explore how QuerySets behave under different scenarios.

We know that building beautifully designed Mobile and Web Apps from scratch can be frustrating and very time-consuming. Check Envato unlimited downloads and save development and design time.

That's just the basics. If you need more deep learning about Python, Django, FastAPI, Flask, and related, you can take the following cheap course:

Thanks!

Learning Django QuerySet internals – Understand lazy evaluation and caching

Learn how Django QuerySets work internally, including lazy evaluation, QuerySet caching, query execution, and performance optimization techniques with examples.

Table of Contents:

Prerequisites

What Is a Django QuerySet?

Understanding Lazy Evaluation

Why Lazy Evaluation Matters

When Does a QuerySet Actually Execute?

Common Evaluation Triggers

Iteration

Converting to a List

Using len()

Boolean Evaluation

Accessing an Item by Index

Calling first()

Aggregations

Viewing the SQL Generated by Django

QuerySet Chaining and Immutability

Understanding QuerySet Caching

First Evaluation

Second Evaluation Uses the Cache

Inspecting the Internal Cache

Visualizing the QuerySet Lifecycle

When QuerySet Cache Is Not Reused

Example: Cache Not Shared Between QuerySets

Understanding QuerySet Cloning

count() vs len(): Understanding the Difference

Using count()

Using len()

Performance Comparison

Recommendation

exists() vs len() > 0

Caching and Memory Considerations

Using iterator() to Disable Caching

Demonstrating Caching with Django Debug Toolbar

Avoiding N+1 Query Problems with select_related() and prefetch_related()

What Is the N+1 Query Problem?

Why Does This Happen?

Visualizing the Problem

Solving the Problem with select_related()

How select_related() Works Internally

Confirming with Django Debug Toolbar

Understanding prefetch_related()

Using prefetch_related()

How prefetch_related() Works Internally

Step 1

Step 2

Step 3

Choosing Between select_related() and prefetch_related()

Use select_related() for:

Use prefetch_related() for:

Quick Comparison

Combining Both Techniques

Common Mistakes

Accessing Related Objects Inside Loops

Forgetting About Reverse Relationships

Overusing Prefetching

Best Practices for Related Data Loading

QuerySet Internals Recap

Common QuerySet Pitfalls and Performance Best Practices

Pitfall 1: Evaluating QuerySets Too Early

Best Practice

Pitfall 2: Using len() for Record Counts

Best Practice

Pitfall 3: Using len() or Boolean Checks for Existence

Best Practice

Pitfall 4: Triggering N+1 Queries

Best Practice

Pitfall 5: Loading Large QuerySets into Memory

Best Practice

Pitfall 6: Repeating Similar Queries

Best Practice

Performance Optimization Checklist

Query Construction

Counting and Existence Checks

Related Objects

Large Datasets

Debugging

Conclusion

Related Articles

Avoiding N+1 Query Problems with `select_related()` and `prefetch_related()`

Solving the Problem with `select_related()`

How `select_related()` Works Internally

Understanding `prefetch_related()`

Using `prefetch_related()`

How `prefetch_related()` Works Internally

Choosing Between `select_related()` and `prefetch_related()`

Use `select_related()` for:

Use `prefetch_related()` for:

Pitfall 2: Using `len()` for Record Counts

Pitfall 3: Using `len()` or Boolean Checks for Existence