Benchmarks · The datasheet

Numbers we can defend.

every figure below carries its own test conditions · measured July 2026 on Pyxle 0.7.1 · not re-measured for the 0.9 line

01 · SSR

The SSR reference.

the full page, re-rendered per request · per core · the JS incumbent, for scale

FIG 01 · dynamic SSR throughput, per core

Landing pagehero, feature grid, stats — a typical marketing home2.20×

pyxle1,151 req/s · p50 84 ms

next.js524 req/s · p50 183 ms

300-row data tablea large inventory table, fully server-rendered2.11×

pyxle158 req/s · p50 644 ms

next.js75 req/s · p50 1,344 ms

Nested dashboardstat cards, grouped category cards, and a data table2.30×

pyxle237 req/s · p50 419 ms

next.js103 req/s · p50 983 ms

API route, same appa JSON endpoint served through each full SSR app5.48×

pyxle11,784 req/s · p50 8 ms

next.js2,149 req/s · p50 45 ms

conditions — Pyxle 0.7.1 (Starlette 0.37.2) vs Next.js 16.2 (React 19.2), force-dynamic · single worker per core pass · 100 connections · July 2026 · median of 3 reps · parity-verified DOM · roughly half the median latency at every page complexity

02 · The field

The Python field first.

identical endpoints, parity-verified · 8 workers · 100 connections · req/s, higher is better

FIG 02 · identical endpoints, side by side

parse a JSON body · validate fields · respond — the request-processing pipeline

Pyxle52,438

FastAPI47,125

Flask21,264

Django8,576

the reading — JSON: parity with FastAPI (±3%) · health ping: ~5% behind · form POST and the multi-query pages: ahead · single-row read: ~10% behind — and Pyxle carries its full middleware stack (SSR · gzip · server actions) in every run · versions in the method · July 2026 · median of 3 reps

03 · Scaling

One flag, every core.

same app, same 8-core box · no load balancer, no shared state — an independent process per core

FIG 03 · workers 1 → 8

JSON serialization59,766 · 5.1×

Form POST52,438 · 4.9×

Single DB query29,299 · 7.7×

Five-query page24,681 · 12.6×

the reading — mean 9.0× across the six API tests; FastAPI does 7.4× on the same move · multi-query passes 8× because one worker serializes its blocking SQLite reads and eight overlap them · per core the optimized Node runtimes still lead · requires Pyxle 0.4.3+ · July 2026 · median of 3 reps

04 · Losses

Where Pyxle loses.

a benchmark page that only shows wins is an ad · same boxes, same run

FIG 04 · raw JSON — nothing to render

Hono212,528

FastAPI61,565

Pyxle59,766

Hono — an ultralight with no SSR — is ~3.5× ahead, and FastAPI edges Pyxle by a few percent on JSON and the bare health ping · the off-box generator is what keeps this gap visible · July 2026 · median of 3 reps

FIG 05 · single DB read — one random row

Hono172,870

Express47,937

FastAPI32,319

Pyxle29,299

native better-sqlite3 bindings own the single read, and FastAPI leads by ~10% · add real work and it flips: Pyxle 24,681 vs FastAPI 22,013 on the five-query page · July 2026 · median of 3 reps

05 · Bytes

Same DOM, fewer bytes.

HTML per response, per-request pages only — static content caches equally on both

FIG 06 · bytes on the wire — lower is better

Landing pagewhole HTML document, per response39% the bytes

pyxle5.4 KB

next.js13.7 KB · includes the RSC hydration payload

300-row data tablethe table page, fully rendered44% the bytes

pyxle145 KB

next.js332 KB · includes the RSC hydration payload

conditions — equivalent SSR DOM, verified before the run · production builds · measured July 2026 · the difference is the hydration blob Pyxle never ships

06 · Method

How the numbers were made.

two boxes, one job each — the load generator is never the ceiling

server box · c7i.2xlarge8 vCPU · 8 workers · the framework under test, in native multi-process production mode

generator box · c7i.2xlargeoha v1.14 · 100 connections · off-box over the private network

protocol12 s per test · 8 s warm-up · median of 3 reps

parityidentical JSON shape + equivalent SSR DOM, verified before every run — or the run aborts

databaseSQLite (WAL) · 1,000 pre-seeded rows · persistent per-worker connection

per-core passa separate single-worker pass measures per-core throughput

correctness0 errors · 0 non-2xx · 0 timeouts across the suite

versionsPyxle 0.7.1 (Starlette 0.37.2) · Hono 4.12 · Express 5.2 · Next.js 16.2 (React 19.2) · FastAPI 0.139 · Django 5.2 · Flask 3.1 · Node 22.23

serverspyxle serve --workers 8 (full middleware) · uvicorn+uvloop · gunicorn · Node cluster · 8× next start

the 0.9 linenot re-measured — a real 0.7.1 figure, said plainly, over an estimate

harnessgithub.com/pyxle-dev/benchmarks → — endpoint implementations, the Next.js apps, parity checks, raw runs

07 · Real world

This site is the live specimen.

pyxle.dev is a Pyxle app, server-rendered per request · Lighthouse desktop preset, production build

100Performance

100Accessibility

100Best Practices

100SEO

verify on PageSpeed Insights →

08 · Reproduce

Run them yourself.

the harness, the apps, the parity checks — all in the repo

quick rungenerator on your machine — fine for relative standings; absolute numbers read low

published flowtwo boxes: ./bench.sh --serve-only --workers=auto · ./bench.sh --generate-only --target=<server-ip> --suite=all

in the repoendpoint implementations · the Next.js apps · parity checks · SSR test pages · step-by-step README

view benchmark source →how this compares →read the docs →