django-fastdrf

Opt-in serializer, query and response optimizations for synchronous Django REST framework projects.

django-fastdrf is for DRF projects that stay synchronous (WSGI, or ASGI with synchronous views) and want less time per request without leaving DRF. It adds subclasses, mixins and settings next to DRF's own classes. Each optimization is enabled explicitly, per project, per view or per serializer, and falls back to DRF's code wherever it cannot produce DRF's result.

It does not replace or patch any Django or DRF class, add async support, or change DRF's validation errors.

Installation

pip install django-fastdrf

The distribution is django-fastdrf; the import name is fastdrf. Extras install the optional parts:

pip install "django-fastdrf[msgspec]"      # msgspec backend, renderer, parser, codec
pip install "django-fastdrf[pydantic]"     # pydantic backend, schema serializers, codec
pip install "django-fastdrf[spectacular]"  # OpenAPI for schema serializers

Adding "fastdrf" to INSTALLED_APPS is optional. It registers system checks, two management commands and, with drf-spectacular, the OpenAPI extension for schema serializers; everything else works without it.

Quick start

Use fastdrf's serializer bases and choose a backend for their output:

# settings.py
FASTDRF = {
    "SERIALIZER_BACKEND": "msgspec",  # or "pydantic", or "python" (no dependency)
    "CACHE_SERIALIZER_FIELDS": True,
    "FIELD_COPY_MODE": "compiled",
}

# serializers.py
from fastdrf import serializers


class ArticleSerializer(serializers.ModelSerializer):
    class Meta:
        model = Article
        fields = ["id", "title", "author", "published_at"]
        auto_prefetch = True

# views.py
from rest_framework import viewsets

from fastdrf.views import DispatchOptimizationMixin, QueryOptimizationMixin


class ArticleViewSet(
    DispatchOptimizationMixin, QueryOptimizationMixin, viewsets.ModelViewSet
):
    queryset = Article.objects.all()
    serializer_class = ArticleSerializer

.data, .is_valid(), .save(), many=True, routers, pagination, permissions and error responses are DRF's. With "fastdrf" in INSTALLED_APPS, this command lists which serializers the backend compiles, and why the others stay on DRF:

python manage.py fastdrf_inspect_serializers

Features

Serialization:

• Compiled serializer output with the msgspec, pydantic or dependency-free python backend, equal to DRF's .data in the default strict parity mode (serializers).
• Input recognition: JSON input that DRF would accept unchanged is validated by a compiled class; everything else, including every error, is DRF's (input recognition).
• Cached field templates, copied per request with deepcopy, a scalar clone or a compiled copy plan (field caching).
• List serializers whose child refers to the list weakly (list serializers).
• Schema serializers: a msgspec Struct or a pydantic model as a DRF serializer, and SchemaViewMixin for views (schema serializers).

Queries:

• select_related and prefetch_related derived from the serializer by QueryOptimizationMixin, explicit Meta.prefetch hints, Django 6.1's FETCH_MODE, one query for many-valued primary-key input, and PrefetchListSerializer for per-list enrichment (queries).

Views and responses:

• Dispatch mixins that keep content negotiation and request construction between requests, compiled create and update responses, a Response that releases its request objects when closed, and DataResponse, rendered without DRF's template response (views and responses).
• A JSONRenderer that keeps its encoder, msgspec's JSON renderer and parser, and msgspec and pydantic codecs for Django's Redis cache (rendering and codecs).

Tooling:

• System checks for the FASTDRF setting and two management commands: fastdrf_inspect_serializers and fastdrf_convert, which writes a schema for a serializer or a serializer for a schema (commands).

Guarantees and limits

• No Django or DRF class is replaced, patched or monkeypatched. fastdrf's classes are subclasses and mixins that a project selects.
• Everything is opt-in. With the default settings, fastdrf's serializer bases behave as DRF's.
• In strict parity, compiled output equals DRF's output; a field, value or hook the compiler cannot prove equal keeps the serializer, or that one source, on DRF. Input recognition never produces an error of its own.
• Synchronous only: no ORM call becomes asynchronous, and transactions, authentication, permissions, throttling and pagination are DRF's and Django's.
• Schema serializers, fast parity and the msgspec renderer have their own documented output and validation rules; they are not DRF-identical by design.
• A serializer instance belongs to one request; do not share it between threads.

See architecture for how the caches are bounded and invalidated, and for the deliberate differences.

Compatibility

The test suite also runs on free-threaded Python 3.14t (Django 6.1, DRF 3.18) and at the declared minimum versions (Django 5.2, DRF 3.16, msgspec 0.19, pydantic 2.9). FETCH_MODE needs Django 6.1.

Documentation

• Documentation index
• Configuration reference
• Example project: the same API with plain DRF and with fastdrf, with parity tests and a measurement script
• Changelog
• Contributing
• Security policy

License

BSD 3-Clause. See LICENSE and NOTICE: the optimizations derive from the aiodrf project, and the list-construction protocol from Django REST framework.