Benchmarks¶

Stock Django against djox, on the same machine and the same data.

Run¶

cd benchmarks
uv sync --reinstall-package djox     # builds djox from this checkout
uv run python run.py                 # ORM calls, SQLite (~2 min)
uv run python postgres.py            # ORM calls, Postgres (needs DJOX_POSTGRES_URL)
cargo install oha                    # the HTTP load tool, once
uv run python web/load_test.py       # web app, SQLite and Postgres (~30 min)

• Postgres scripts use DJOX_POSTGRES_URL (default postgresql://postgres:postgres@localhost/postgres) and create their own database on that server.
• Results go to results/*.json. Each script prints its Markdown table.
• All numbers below: Linux x86_64, 4-core cloud VM, Python 3.13, Django 6.1, Postgres 16 on the same VM.
• This VM's speed moves by about 20% between runs. Compare within one table, not across tables.

Web app: requests per second¶

A small shop app (web/app.py): 100 authors, 10,000 books.

• Endpoints, each written three ways (plain sync views, async views, a DRF ModelViewSet):
• get one book (random id)
• list a page of 20 books with their authors: a count() and a select_related() join (random page)
• update a book (PATCH), create a book (POST)
• a page of 20 authors with their books' stats: annotate(Count("books"), Sum("books__pages")), a GROUP BY over a join
• one author's stats: aggregate(Avg(), Max(), Sum()) of their 100 books
• count a read of a book (POST): update(read_count=F("read_count") + 1)
• Stacks: the same code. djox only changes settings: its ENGINE, and "djox" in INSTALLED_APPS.
• Server: granian, one worker process, one thread. WSGI for sync views and DRF, ASGI for async views: Django's handler on Django, djox's (djox.asgi) on djox. No middleware.
• Connections: kept between requests under WSGI. Under ASGI, CONN_MAX_AGE = 0, as Django's docs advise. On Postgres, Django's own connection pool ("pool": True).
• Load: oha, 32 connections, 2 s warm-up, then 5 s per endpoint. Stacks take turns, round after round (3 by default, --rounds 5 for more); each number is the median. No request failed.

Requests per second, higher is better. In brackets: djox against Django.

SQLite:

Postgres:

Annotations, aggregates and F() on SQLite, measured after the tables above, with djox before and after the general fast lane (3 rounds, the same load):

• aggregate() and update() with F() now take the fast lane: one author's stats serve 3 times the requests of djox before, sync or async.

• Authors with stats are bound by SQLite: the GROUP BY over 10,000 books takes most of each request, so the fast lane adds a quarter to a third.

• Async views: 2.9 to 13.3 times the requests. Django runs every async query on its one worker thread, and its ASGI handler hops to threads for each request's signals. djox runs the queries on its own connections (small SQLite reads right on the event loop's thread), and its handler sends the signals on the loop.

• The gap between async and sync views mostly closes. On Postgres, djox's async views serve more requests than its sync views. On SQLite they serve a third to two thirds as many; Django's serve about a tenth.
• Sync views: 1.1 to 2.2 times, from the fast lane: reads, updates, select_related() pages, and create().
• DRF: up to 1.3 times. DRF's router passes the id from the URL as text (pk="5"), which the fast lane takes since #15. DRF spends most of each request in its own code (serializers, permissions, rendering), so it gains less than plain views. The DRF columns come from an earlier run (5 rounds, on a faster moment of this VM than the other columns): compare them with each other.
• Postgres moves more between rounds (every query is a network round trip on the same 4 cores). Differences under about 10% are noise.

ORM calls on SQLite¶

The same queries through each contender, on a SQLite file with 10,000 books, each with 3 chapters (run.py). Microseconds per call, median of 5 rounds, lower is better.

• The fast lane makes sync code 3 times faster: get() 64 µs against 218, count() 93 against 290.
• Async aget() is 10 times faster than Django's (51 µs against 517), and 1,000 books 3 times. A small read runs right on the calling thread (quick reads), within 50 µs of hand-written SQL.
• select_related() takes the fast lane too: 20 chapters with their book take 219 µs sync against 744, and 206 µs async against 1,245. Django writes the join once; Rust builds both objects of each row.
• Annotations, aggregates and F() take the fast lane too (the general fast lane: any chain of calls reuses the SQL Django wrote once for its shape). Measured before and after it, in one run of the same VM:

• create() takes the fast lane: acreate() 268 µs against 441, create() 145 against 183. Django writes the model's INSERT once.
• prefetch_related() gains less (1.9 ms against 2.4 ms async): the prefetching query still runs Django's code.
• djox's ENGINE alone costs about nothing: "djox sync" is within noise of Django.
• A short djox.atomic() block is slower than one sync_to_async() around a sync atomic(): it pays a thread round trip per statement. What it buys is async code inside the transaction.
• Writes, and reads too slow to run inline, take a round trip to djox's threads: 60 to 90 µs on this VM (update one book: 115 µs in the "djox" column, against 10 µs for SQLite itself).

ORM calls on Postgres¶

The same queries on Postgres (postgres.py), 10,000 books. Microseconds per call, lower is better.

• Contenders as above. psycopg is the floor; "djox" is djox.Database.postgres() with hand-written SQL.
• Sync code stays on psycopg (Django's Postgres backend); async code runs on djox's Rust pool.
• Async aget() is 3.5 times faster than Django's (258 µs against 917), and 100 at once 4 times faster.
• Raw djox is as fast as psycopg's AsyncConnection, and has a pool: 100 gets at once take 53 µs each.
• The fast lane halves a sync get() on Postgres too, though it still runs on psycopg.
• Short djox.atomic() blocks are slower, as on SQLite.
• Each query is a network round trip here, so numbers move by 20 to 30% between runs.