Which backend is fastest — and why the answer rarely matters.

Ask which backend is fastest and you will be shown a bar chart. For twelve years that chart came from the TechEmpower Framework Benchmarks, which archived in March 2026 — in part because the numbers had drifted away from anything resembling a real application. The honest answer to the question is that language choice is almost never what makes your API slow, and this guide explains what is.

What the last round actually measured

Round 23 of the TechEmpower Framework Benchmarks, published March 2025 and the final round before the project archived. The Fortunes test is the most application-like of the suite (database read, sort, HTML render). Absolute numbers are not comparable to earlier rounds: Microsoft donated 56-core servers on a 40Gbps network mid-project, which raised network-bound results by 3–4x. Read the ordering, not the figures.

Why the benchmark king stopped being the answer

The TechEmpower repository went into archived mode on 24 March 2026, after a final round covering more than 330 framework implementations. The criticisms that preceded it are the useful part: the test platform had barely changed in years, results were capped by the harness rather than by the frameworks, and entries were allowed to use low-level optimisations no team would ship in a real product. A framework could top the chart with code its own documentation would not recommend.

A successor project, HttpArena, is attempting the same job with HTTP/2 and WebSocket support and deliberately realistic implementations. Until it has comparable coverage, treat every "fastest backend 2026" chart you see as a rough ordering of ceilings, not as a prediction about your application.

Where your response time actually goes

On a typical business API, the language spends single-digit milliseconds and everything else spends the rest. An unindexed database query, an N+1 pattern that fires 200 queries where one would do, a synchronous call to a payment or CRM provider, a missing cache on a response that changes hourly — any one of these costs more than the entire gap between the fastest and slowest stack in the table above.

This is why rewriting a slow Node service in Go usually disappoints. If 480ms of a 500ms response is a query waiting on a database, moving the remaining 20ms to 5ms is a 3% improvement for a full rewrite. Fixing the query is a 90% improvement for an afternoon.

What we actually choose, and why

Node.js with TypeScript is our default, mostly for a non-performance reason: it is the same language as the Next.js front end, so types, validation logic and utilities are shared rather than reimplemented and kept in sync by hand. For I/O-bound work — which is most business software — its event loop is genuinely well suited, and the table above measures Express, not the faster runtimes now available in the same ecosystem.

Go is what we reach for when a service must hold many thousands of concurrent connections cheaply, or when a single small binary with predictable memory is operationally valuable. Python earns its place wherever machine learning or data tooling is involved, because the libraries are there and nothing else is close. Java is the right answer when it is already the house stack and a team exists to maintain it. Rust we recommend rarely and specifically: sustained CPU-bound throughput where the hosting bill scales with efficiency.

When the language genuinely is the bottleneck

It does happen. Real-time systems with tens of thousands of persistent connections, per-request CPU work like image or video transformation, high-frequency data ingestion, or workloads where compute cost is a material line on the P&L — in those cases the runtime's efficiency is a business number, not a preference.

The tell is measurement, not intuition. If profiling shows CPU saturated inside your own code rather than time spent waiting on other systems, the language matters. Otherwise you have a database, caching or architecture problem wearing a language problem's clothes.

The criteria that beat raw speed

Who will maintain this in three years, and can you hire them. How mature the libraries are for the specific integrations you need. How fast a fix ships when something breaks at 9am. How much the hosting costs at your actual traffic, not at 600,000 requests per second. A stack that is 4x slower on a synthetic benchmark and 2x faster to change is the better commercial choice for almost every business application.

Fast enough is a real engineering target. Define it — say, 200ms at the 95th percentile under expected load — then pick the stack your team can keep meeting it with.

Sources

Benchmark figures and the archival timeline come from these, checked July 2026.

• TechEmpower Framework Benchmarks — Round 23 ↗

  Final published round of the project, covering more than 330 framework implementations across the plaintext, JSON, single-query, multi-query, fortunes and updates tests.

• TechEmpower — Framework Benchmarks Round 23 announcement ↗

  Published 17 March 2025. Documents the hardware change — HPE ProLiant DL360 Gen10 Plus, 56-core Xeon Gold 6330, 40Gbps Mellanox networking — and the resulting 3–4x jump in network-bound results.

• DEV — TechEmpower Framework Benchmarks are now archived: what's next? ↗

  Records the 24 March 2026 archival, the stagnation and unrealistic-optimisation criticisms, and HttpArena as the proposed successor.