Skip to content
backend

Why Your REST API Should Embrace Django Querysets Instead of Raw SQL

5 min read
django rest api querysets raw sql backend

Also available in Spanish

Introduction

Let’s cut to the chase: if you’re building a REST API in Django and sprinkling raw SQL all over your codebase, you’re probably doing more harm than good. I get it—raw SQL is tempting. It feels closer to the metal, gives you control, and can sometimes look more efficient. But when you’re working in Django, leaning on its ORM and using Querysets isn’t just a “convenience.” It’s a smarter, safer, and more scalable choice.

Let’s unpack why Django Querysets should be your default, and where raw SQL might still belong (if it belongs at all).

The Case for Querysets

If you’re not using Querysets for your database interactions, you’re effectively throwing away one of Django’s biggest strengths: its ORM. A queryset is more than just a way to fetch data—it’s an abstraction layer that solves many problems you don’t want to deal with manually.

1. Querysets Are Safer

Let’s talk about SQL injection, the boogeyman of sloppy database code. Raw SQL queries are notoriously prone to injection vulnerabilities if you’re not crafting them with extreme care. Here’s a nightmare scenario:

# Example of raw SQL that opens the door for SQL injection
def get_user_by_email(email):
    with connection.cursor() as cursor:
        query = f"SELECT * FROM users WHERE email = '{email}'"
        cursor.execute(query)
        return cursor.fetchall()

# Someone passes this email to your API:
email = "' OR 1=1 --"
result = get_user_by_email(email)

Boom. You’ve just handed over your database to a malicious actor.

Now contrast this with Django Querysets:

# Using Django Querysets
from django.contrib.auth.models import User

def get_user_by_email(email):
    return User.objects.filter(email=email)

Django’s ORM automatically escapes inputs, making injection attacks significantly harder. This isn’t just a nice-to-have—it’s table stakes for modern web development.

2. Querysets Are More Expressive

Raw SQL usually means you’re writing more boilerplate code just to get the job done. Querysets, on the other hand, let you focus on what you want to accomplish rather than how to wrangle the database.

Here’s an example of querying for active users created in the last 7 days:

from datetime import timedelta
from django.utils.timezone import now

# Queryset example
active_users = User.objects.filter(is_active=True, date_joined__gte=now() - timedelta(days=7))

Now here’s the raw SQL equivalent:

import datetime
from django.utils.timezone import now
from django.db import connection

def get_active_users():
    seven_days_ago = now() - datetime.timedelta(days=7)
    with connection.cursor() as cursor:
        query = """
        SELECT * FROM users
        WHERE is_active = TRUE
        AND date_joined >= %s
        """
        cursor.execute(query, [seven_days_ago])
        return cursor.fetchall()

Notice two things:

  1. The raw SQL version is longer and harder to read.
  2. You’re manually managing placeholders (%s) and parameters, which adds cognitive overhead.

Querysets abstract away this mess, letting you focus on your business logic.

3. Querysets Are Database-Agnostic

One of Django’s superpowers is its database-agnostic ORM. You can switch from PostgreSQL to MySQL, SQLite, or even Oracle without rewriting all your queries. If you’re married to raw SQL, though, good luck with that migration.

Let’s say you’ve been writing raw SQL tailored for PostgreSQL, using syntax like ILIKE or data types like JSONB. The day you need to switch to another database, your raw SQL queries will break spectacularly.

Querysets sidestep this problem entirely. For example:

# Case-insensitive search with Querysets
users = User.objects.filter(email__icontains="example.com")

Django handles the differences between ILIKE (PostgreSQL) and whatever the equivalent is in other databases. You don’t have to care—your queries will just work.

4. Querysets Are Easier to Debug

Ever stared at a raw SQL query for hours trying to figure out why the data doesn’t look right? Querysets make debugging easier because:

  1. You can log the generated SQL (print(queryset.query)).
  2. You’re working at a higher level of abstraction, which makes logic easier to reason about.

For instance:

# Print the SQL behind a queryset
queryset = User.objects.filter(is_active=True)
print(queryset.query)

This lets you see exactly what Django is sending to your database without losing the readability of your Python code.

When Raw SQL Might Make Sense

Alright, I’ll admit it: there are edge cases where raw SQL can outperform Querysets. These usually fall into one of two categories:

1. Complex Queries Django Can’t Handle

Django’s ORM is powerful, but it’s not omnipotent. If you need to use database-specific features like window functions or recursive queries, raw SQL may be your only option.

Example of a raw SQL query for a running total:

SELECT date,
       SUM(sales) OVER (PARTITION BY region ORDER BY date ASC) AS running_total
FROM sales_data;

Django has been adding support for advanced database features over time (annotate(), Subquery(), etc.), but sometimes raw SQL is unavoidable.

2. Performance Bottlenecks

In rare cases, Django Querysets can be less efficient than finely-tuned raw SQL. For example, if you need to fetch 10 million rows with very specific joins and aggregations, raw SQL may let you optimize the query better.

That said, always benchmark before assuming raw SQL is faster. Django Querysets are often good enough, and premature optimization can lead to unnecessary complexity.

Practical Tips for Working With Querysets

Let me share some tips to maximize your Queryset usage without losing flexibility.

Tip 1: Learn the Power of annotate() and aggregate()

Django Querysets can handle complex aggregations and calculations if you know how to use these methods:

from django.db.models import Count

# Count the number of active users per group
group_counts = Group.objects.annotate(num_users=Count('user'))

Tip 2: Debugging Querysets with SQL

If things aren’t behaving as expected, print the SQL query behind your Queryset:

queryset = User.objects.filter(is_active=True)
print(queryset.query)

This is a lifesaver for debugging.

Tip 3: Avoid the N+1 Query Problem

Don’t accidentally turn your Querysets into an N+1 query mess. Use .select_related() and .prefetch_related() to efficiently fetch related data:

# Efficiently fetch related objects
users = User.objects.select_related('profile')

Conclusion

Django Querysets aren’t just a convenience—they’re a best practice for REST API development. They’re safer, more expressive, and easier to debug, while also keeping your codebase database-agnostic. Yes, raw SQL has its place for edge cases, but it shouldn’t be your default.

If you’re reaching for raw SQL out of habit or perceived performance gains, take a step back. Nine times out of ten, Django’s Querysets will do the job better, faster, and with less risk.

So next time you’re tempted to write raw SQL in your Django project, ask yourself if there’s a Queryset method that could get the job done instead. Odds are, there is—and it’s the smarter choice.

Back to blog