QuerySets are lazy — when Django actually hits the database

Chaining .filter(), .exclude(), .order_by(), and similar methods only builds up a description of the SQL to eventually run — internally, an unevaluated QuerySet is closer to a query plan than a result set. This is genuinely useful: it means you can build a query across several function calls, conditionally add filters, and pass the whole thing around, all without touching the database — the actual SQL is assembled once, right before it's needed, from every filter that got chained on.

A fixed list of operations force Django to run the query and fetch results:

Once a QuerySet has been evaluated, Django caches the result internally, so re-iterating the same QuerySet object doesn't re-hit the database. The trap is when you don't realize you're building a new QuerySet each time:

The fix isn't a Django trick — it's ordinary code hygiene: evaluate once, store the result, reuse the Python list.

Use .count() if you haven't touched the queryset yet and only need a number. Use len(qs) if you've already iterated it earlier in the same view — the data's already in memory, so a second .count() query would be strictly wasteful. Use .exists() for a plain yes/no question, since it's the only one of the three that can stop as soon as it finds a single matching row instead of processing all of them.