A black and white silkie chicken, the cppdjango mascot

A C++ port of Django 6.0.7

Django 6.0.7. Ported to C++.

cppdjango is an open-source C++ port that keeps Django’s familiar API and behavior while moving performance-critical ORM paths into native code. The evidence: 436% faster framework-side ORM work across a balanced mix of measured PostgreSQL operations.

Install cppdjango → See the benchmark evidence
PyPI release 6.0.7.post1 548 ORM correctness tests Same SQL and data
436%faster ORM-only CPU performance across the balanced suite
81.4%less CPU spent inside framework ORM work
<1.4%PostgreSQL task-CPU difference between implementations
0 hooksPython field-lookup or preparation calls in supported terminals

Install cppdjango 6.0.7.post1

Keep your Django imports.

Install the cppdjango distribution in a fresh virtual environment. Applications continue to use import django and the normal django-admin command.

The package includes native code. pip uses a compatible wheel when available and otherwise needs CMake, a recent C++26 compiler, OpenSSL, and zlib to build the extension.

Full installation guide → cppdjango on PyPI → Source on GitHub →
Fresh virtual environment
$ python3 -m venv .venv
$ . .venv/bin/activate
$ python -m pip install --upgrade pip
$ python -m pip install cppdjango==6.0.7.post1

# Verify the Python and native release identities
$ python -c "import django; from django import native; print(django.__version__, native.version(), native.compiler())"

Use one distribution: cppdjango replaces upstream Django. Do not install Django and cppdjango together because both own the django import namespace.

Measured evidence

The C++ port earns its place with one honest number.

“Faster” here means more ORM operations for the same worker CPU. It does not mean PostgreSQL became faster, and it does not claim that every Django API is four times faster. It measures the framework work cppdjango actually replaces.

The aggregate gives one vote each to a point select, an ordered 32-row IN select, and a point update. Different production mixes will produce different totals, so the operation-level results remain visible below.

Across a balanced mix of measured PostgreSQL operations, cppdjango’s framework-side ORM work is 436% faster than stock Django 6.0.7.

Equivalent statement: cppdjango uses 81.4% less ORM CPU. Shared cursor/psycopg CPU and PostgreSQL CPU are excluded from this claim.

Stock ORM-only CPU 429.48 µs
cppdjango ORM-only CPU 80.06 µs
CPU performance 5.36×

The unrounded ratio gives 436.4%, conservatively shown as 436%. The totals are one operation of each measured query shape.

Framework CPU / lower is better

The C++ path removes the expensive Python query machinery.

These bars show worker CPU after subtracting a matched raw cursor call. That isolates query construction, ORM compilation, facade work, and framework result handling—the portion cppdjango can change.

Measured worker CPU per completed database operation, in microseconds.
Query Raw cursor floor
stock / C++		 Total worker
stock / C++		 ORM-only
stock		 ORM-only
C++		 ORM CPU
reduction		 CPU performance
Point select 65.44 / 65.59 206.42 / 89.95 140.98 24.36 82.7% 5.79×
Ordered IN32 80.36 / 80.40 276.87 / 113.08 196.51 32.68 83.4% 6.01×
Point update 65.31 / 65.08 157.30 / 88.10 91.99 23.01 75.0% 4.00×

ORM-only CPU = ORM worker CPU − the same build’s raw Django cursor/psycopg CPU. Using a per-build floor avoids assigning small installation variance to either framework.

Why the raw score is less heroic

The C++ ORM cannot optimize PostgreSQL.

Once cppdjango removes most framework work, the database and the shared cursor/driver path dominate. They account for 84–90% of current per-query CPU in these shapes. That fixed bill puts a hard ceiling on end-to-end gains.

01 / Point select

263.78 → 146.54 µs total CPU

44.4% less

PostgreSQL is 38.6% of current combined CPU; cursor/psycopg is another 44.8%.

ORM 17%cursor 45%PG 39%
02 / Ordered IN32

367.58 → 204.03 µs total CPU

44.5% less

PostgreSQL is 44.6% of current combined CPU; cursor/psycopg is another 39.4%.

ORM 16%cursor 39%PG 45%
03 / Point update

308.33 → 237.26 µs total CPU

23.1% less

PostgreSQL is 62.9% of current combined CPU; cursor/psycopg is another 27.4%.

ORM 10%cursor 27%PG 63%

Same SQL. Same PostgreSQL work.

Dedicated-backend task CPU was 57.36/56.59 µs for the point select, 90.71/90.94 µs for IN32, and 151.03/149.16 µs for the update. The native/stock difference stayed below 1.4%. The database did not get cheaper; cppdjango simply stopped spending so much Python CPU before and after it. That is why the measured query wall-time ratios—1.83× point, 1.85× IN32, and 1.24× update—are valuable but smaller than the 5.36× framework-only result.

What changed in the fork

One crossing, one compiled terminal.

The hot path keeps primitive predicates in an immutable C++ plan, resolves registered field IDs there, and binds the complete terminal without Python field hooks. Unsupported fields and values replay into Django before execution.

01 / PYTHON

QuerySet facade

Preserve Django’s public API and select a conservative native candidate.

02 / C++

Schema + binder

Resolve field IDs, validate primitives, bind parameters, and compile the terminal.

03 / SHARED FLOOR

psycopg cursor

Execute and decode through the same driver used by stock Django.

04 / DATABASE

PostgreSQL

Run the same SQL plan against the same rows and connection settings.

Controlled methodology

A CPU benchmark, not a stopwatch anecdote.

Worker CPU and PostgreSQL CPU were measured separately so blocked time could not masquerade as framework cost.

Scope boundary

This result covers the measured PostgreSQL ORM fast paths. Cassandra, templates, middleware, unrelated QuerySet shapes, and application code are outside the claim.

  • Baseline6.0.7 baseline
  • NativeNative implementation released as cppdjango 6.0.7.post1; measured with g++ 15.2.0
  • SystemDedicated benchmark machine with 128 logical CPUs
  • RuntimeCPython 3.14.4 and psycopg 3.3.4
  • DatabasePostgreSQL 18.4, 10,000 deterministic World rows
  • ConnectionOne persistent TLS connection per run
  • Warmup500 operations before counters begin
  • Worker counterProcess CPU clock and RUSAGE_SELF, five-second steady state
  • Database counterDedicated PostgreSQL backend task CPU from Linux /proc, sampled at worker boundaries
  • Correctness548 ORM benchmark tests passed; same ordered SQL and PostgreSQL parameter OIDs verified
  • StabilityThree alternating CPU repetitions; equal-work COW validation completed with zero errors

Reproduce, don't trust

The evidence ships with the claim.

The published comparison preserves the exact measured patch, worker process records, PostgreSQL task-CPU records, construction samples, COW validation, boundary audit, and methodology.

https://django.goblinreactor.com/artifacts/
# Published result and headline calculation
$ curl -s https://django.goblinreactor.com/artifacts/benchmark-summary.json

# Final worker, database, and construction samples
$ curl -O https://django.goblinreactor.com/artifacts/cpu-process.csv
$ curl -O https://django.goblinreactor.com/artifacts/cpu-postgresql.csv
$ curl -O https://django.goblinreactor.com/artifacts/construction.csv

# Exact measured patch SHA-256
9b3b89654bda36587ae782aac5cdbaa3d9f6b68257534c81b88053aade0c69da
Public evidence ledger → Summary JSON → Raw CPU CSV → PostgreSQL task CPU → Construction samples → Final COW validation →