Django REST Framework (DRF) serializers make it easy to build clean and powerful APIs. But as a Django application grows, serializers can quietly become a major source of performance problems.

Sometimes the database query is fast. The view is fast. PostgreSQL is healthy. Yet the API endpoint is still slow.

The problem might be the serializer.

The Serializer Is Not Just a Formatter

A common mental model looks like this:

text Database → Serializer → JSON Response

So we naturally assume serialization is cheap.

But a Django REST Framework serializer can execute database queries, access related objects, run Python code, calculate fields, and recursively serialize nested relationships.

Consider this example:

python class VehicleSerializer(serializers.ModelSerializer): customer_name = serializers.SerializerMethodField()

class Meta:
    model = Vehicle
    fields = (
        "id",
        "plate_number",
        "customer_name",
    )

def get_customer_name(self, obj):
    return obj.customer.name

At first glance, this looks harmless.

But if the customer relationship has not been loaded, accessing obj.customer can trigger another database query.

Now imagine returning 100 vehicles.

text 1 query → fetch vehicles 100 queries → fetch customers

That’s the classic N+1 query problem.

The serializer doesn’t look expensive.

The database pays the bill.

SerializerMethodField Can Be Expensive

SerializerMethodField is extremely useful. It’s also very easy to abuse.

For example:

python class ServiceSerializer(serializers.ModelSerializer): last_service = serializers.SerializerMethodField()

def get_last_service(self, obj):
    return (
        Service.objects
        .filter(ownership=obj.ownership)
        .order_by("-created_at")
        .first()
    )

This works perfectly.

But when serializing 500 objects, you may execute the query 500 times.

text 1 query + 500 serializer queries

501 queries

The solution isn’t necessarily to remove SerializerMethodField.

The real solution is to understand where the data should be calculated.

Move Work Into the QuerySet

Instead of asking the database for every object individually, let the database prepare the data.

For example, you can use Subquery:

python from django.db.models import OuterRef, Subquery

last_service = Service.objects.filter( ownership=OuterRef("ownership"), ).order_by("-created_at")

queryset = Vehicle.objects.annotate( last_service_id=Subquery( last_service.values("id")[:1] ) )

Now the database can perform the work as part of the main query.

The serializer becomes simpler:

python class VehicleSerializer(serializers.ModelSerializer): last_service_id = serializers.IntegerField(read_only=True)

class Meta:
    model = Vehicle
    fields = (
        "id",
        "plate_number",
        "last_service_id",
    )

The important idea is:

Don’t make the serializer discover data that the database could have prepared.

Use select_related() for Foreign Keys

For ForeignKey and OneToOneField relationships, select_related() can prevent unnecessary database queries.

python vehicles = Vehicle.objects.select_related("customer")

Now accessing:

python obj.customer.name

doesn’t require another database query for each object.

Without select_related():

text Vehicle query Customer query Customer query Customer query ...

With select_related():

text Vehicle + Customer

in a single SQL query using a JOIN.

Use prefetch_related() for Collections

select_related() and prefetch_related() solve different problems.

Use select_related() mainly for:

• ForeignKey
• OneToOneField

Use prefetch_related() for:

• ManyToManyField
• Reverse foreign key relationships

For example:

python services = Service.objects.prefetch_related("products")

Without prefetching, accessing:

python service.products.all()

can trigger additional queries for every service.

A useful rule is:

text ForeignKey / OneToOne ↓ select_related()

ManyToMany / Reverse FK ↓ prefetch_related()

Nested Serializers Can Multiply the Problem

Nested serializers are powerful, but they can make database performance problems much harder to notice.

For example:

python class ProductSerializer(serializers.ModelSerializer): class Meta: model = Product fields = ("id", "name")

class ServiceSerializer(serializers.ModelSerializer): products = ProductSerializer(many=True)

class Meta:
    model = Service
    fields = (
        "id",
        "products",
    )

Then:

python Service.objects.all()

may look perfectly fine.

But every service now needs its products.

Without prefetching:

text 1 service query + N product queries

And nested serializers can create even deeper chains:

text Service ├── Customer │ └── Address └── Products └── Category

A seemingly innocent API response can become a query explosion.

The Serializer Can Hide Database Access

This is one of the most dangerous parts of Django REST Framework performance optimization.

When reading code like this:

python serializer = ServiceSerializer( queryset, many=True, )

you can’t immediately see how many database queries will happen.

The actual database access may be hidden inside:

python SerializerMethodField

or:

python obj.customer

or:

python obj.products.all()

or a nested serializer.

That’s why optimizing DRF serializers isn’t only about optimizing serializer code.

You have to inspect the entire data access path.

Don’t Return Everything

Another common mistake is creating serializers with huge nested structures.

For example:

json { "id": 1, "customer": { "id": 10, "name": "...", "phone": "...", "address": "...", "vehicles": [...], "services": [...], "invoices": [...] } }

It looks convenient.

But convenience has a cost.

You’re increasing:

• Database work
• Python processing
• Serialization time
• Response size
• Network bandwidth
• Memory usage
• Frontend processing

An API response should contain what the client actually needs, not everything the database knows.

Use Different Serializers for Different Endpoints

Don’t try to create one serializer for every use case.

For example:

text VehicleListSerializer VehicleDetailSerializer VehicleCreateSerializer VehicleUpdateSerializer

A list endpoint usually needs less information:

python class VehicleListSerializer(serializers.ModelSerializer): class Meta: model = Vehicle fields = ( "id", "plate_number", "color", )

While a detail endpoint can provide more information:

python class VehicleDetailSerializer(serializers.ModelSerializer): customer = CustomerSerializer()

class Meta:
    model = Vehicle
    fields = (
        "id",
        "plate_number",
        "color",
        "customer",
    )

This makes the API easier to reason about and often significantly cheaper.

Don’t Optimize Without Measuring

One of the biggest mistakes in performance optimization is guessing.

You might think:

This serializer is probably slow.

Maybe.

But you need evidence.

You can inspect database queries during development, or use profiling tools such as Django Silk to identify slow requests, duplicate queries, and expensive database operations.

The goal isn’t to blindly reduce the number of queries.

The goal is to understand why the queries exist.

The Database Isn’t Always the Bottleneck

Sometimes developers optimize SQL while ignoring Python-side serialization.

Consider an endpoint returning 10,000 objects.

The database query might take:

text 50 ms

But serialization might take:

text 800 ms

In that case, optimizing PostgreSQL won’t solve the main problem.

You need to profile the whole request:

text Request ↓ View ↓ Database ↓ QuerySet evaluation ↓ Serializer ↓ JSON rendering ↓ Response

Every layer can become the bottleneck.

A Practical Django REST Framework Optimization Checklist

When a DRF endpoint becomes slow, check these things first.

1. Count the Database Queries

Ask:

text How many SQL queries does this endpoint execute?

2. Look for SerializerMethodField

Search for:

python SerializerMethodField

Then inspect what each method does.

3. Check Relationship Access

Look for code such as:

python obj.customer obj.owner obj.category obj.products.all()

These can cause additional queries when relationships are not loaded efficiently.

4. Add select_related()

Use it for ForeignKey and OneToOneField relationships when appropriate.

5. Add prefetch_related()

Use it for ManyToManyField and reverse relationships when appropriate.

6. Consider Database Annotations

If you’re calculating values from database data, consider using:

python annotate()

instead of repeatedly querying from Python code.

7. Reduce Nested Data

Ask:

Does the client really need this relationship?

8. Use Specialized Serializers

Don’t force one serializer to serve every endpoint.

9. Measure Again

text Before → Optimize → Measure again

Never assume the optimization worked. Measure it.

The Important Lesson

Django REST Framework serializers are not inherently slow.

The problem is usually how we use them.

A serializer can become expensive when it:

• Executes queries repeatedly
• Accesses unloaded relationships
• Performs expensive Python calculations
• Uses too many nested serializers
• Returns unnecessary data
• Hides database access inside methods

The best optimization is often not inside the serializer itself.

It’s in the QuerySet behind the serializer.

A good DRF architecture often looks like this:

text Database ↓ Optimized QuerySet ↓ select_related / prefetch_related ↓ Annotations ↓ Serializer ↓ Minimal Response

Instead of:

text Database ↓ Huge QuerySet ↓ Serializer ↓ "Let's calculate everything here" ↓ N+1 queries ↓ Slow API

The next time someone tells you:

The database query is fast, so the API should be fast.

Don’t assume they’re right.

Measure the serializer too.

Because sometimes the hidden cost isn’t the query.

It’s everything happening after the query.