YATTA VS
THE FIELD

Live from benchmarks.json — regenerated by GitHub Actions on every push to main. Same runner, same load, no cherry-picking.

Raw /json speed is one thing. Real APIs do auth checks, validate input, and hit the database. We benchmarked the identical route on both stacks: in-process Bearer token check, param validation, SQLite point-read, JSON response. Same 10,000 users, same operations — no network hops in either.

Honest result: on an identical real-world route, Yatta is ~1.18x the throughput of a well-assembled Hono + Drizzle single-process app. Not 7-12x — that old figure compared in-process Yatta against network-hop microservices (an architecture difference, not a framework one). This is the apples-to-apples test.

Methodology: GET /api/user/:id, 2k warmup + 20k requests at 100 concurrency, 3 runs each (fresh server + DB per run), median run reported. In-memory SQLite, 10k seeded users. Absolute req/s is capped by the test VM; the relative gap was consistent across all runs.

Same SQLite file, same table, same 10,000 rows, same operations. The only variable is the ORM. Yatta ships a typed SQLite ORM with zero setup.

Methodology: one shared SQLite file (bun:sqlite), users table with 10k rows, identical PRAGMAs for both ORMs. 500 warmup + 5,000 timed iterations per operation, 3 full runs; reported = median of per-run medians. Lower is better.

Estimated hours for one developer to ship a complete app. These are estimates based on the number of packages to configure — not measured stopwatch times.

Shorter bar = faster to ship. Yatta wins because auth, DB, validation, and jobs are built in — no assembly required.

Yatta ships these ten capabilities through its core runtime. Competing frameworks generally compose them through additional official or community packages (like @nestjs/* or @adonisjs/*) — each with its own config, version drift, and docs to manage.

Real RSS measurements — each framework’s /json server in its own OS process, 10k requests at 50 concurrency, RSS read from the OS.

Methodology: each framework's /json server in its own OS process, 10,000 requests at 50 concurrency, RSS read from the OS. Two rounds averaged. Lower is better.

Scores are editorial (1–10 per criterion). Weights: Performance 15%, Developer experience 15%, Architecture 15%, Ecosystem 15%, TypeScript 10%, Database / ORM 10%, Security 5%, Testing 5%, Deployment 5%, Maturity 5%. Total = Σ(score × weight). Reproduce it: the weights, per-framework scores, and formula live in app/compare/page.tsx in this repo.

Scores are editorial (1–10 per criterion). Weights: Performance 15%, Developer experience 15%, Architecture 15%, Ecosystem 15%, TypeScript 10%, Database / ORM 10%, Security 5%, Testing 5%, Deployment 5%, Maturity 5%. Total = Σ(score × weight). Reproduce it: the weights, per-framework scores, and formula live in app/compare/page.tsx in this repo.

Scores are editorial (1–10 per criterion). Weights: Performance 15%, Developer experience 15%, Architecture 15%, Ecosystem 15%, TypeScript 10%, Database / ORM 10%, Security 5%, Testing 5%, Deployment 5%, Maturity 5%. Total = Σ(score × weight). Reproduce it: the weights, per-framework scores, and formula live in app/compare/page.tsx in this repo.

Task dispatch throughput across worker runtimes. Same machine, same test methodology: 20,000 echo tasks across 4 workers, measuring throughput, p99 latency, memory, and IPC round-trip cost.

Methodology: 20,000 ping-pong tasks dispatched across 4 workers. Throughput = tasks/second. p99 = 99th percentile task latency. IPC = single round-trip postMessage cost. All measured on the same machine, same day.