Ask which backend is fastest and somebody shows you a bar chart. For twelve years that chart came from the TechEmpower Framework Benchmarks, and in March 2026 the repository went into archived mode after a final round covering more than 330 framework implementations.
The archival is more useful than anything in the last round, because of why it happened.
What the chart was actually measuring by the end
The criticisms that preceded the archive are the part worth keeping. The test platform had barely changed in years. Results were being capped by the harness rather than by the frameworks under test. And entries were allowed to use low-level optimisations no team would ever ship in a real product, which meant a framework could top the chart running code its own documentation would advise against.
There is a successor attempt, HttpArena, aiming at the same job with HTTP/2 and WebSocket support and deliberately realistic implementations. Until it has comparable coverage, treat every "fastest backend 2026" chart as a rough ordering of ceilings rather than as a prediction about your application.
For the record, the final round's Fortunes test — the most application-like of the suite, since it does a database read, a sort and an HTML render — put ASP.NET on C# around 610,000 requests per second, Fiber on Go around 338,000, Actix on Rust around 320,000, Spring on Java around 244,000 and Express on Node around 78,000. Read the ordering, not the figures: Microsoft donated 56-core servers on a 40Gbps network partway through the project, which lifted network-bound results by three to four times and made absolute numbers incomparable with earlier rounds.
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 query. An N+1 pattern firing 200 queries where one would do. A synchronous call out to a payment or CRM provider that is having a slow afternoon. A missing cache on a response that changes hourly. Any one of those costs more than the entire gap between the fastest and the slowest stack in that list.
This is why rewriting a slow Node service in Go so often disappoints the people who authorised it. If 480 milliseconds of a 500 millisecond response is a query waiting on a database, moving the remaining 20 milliseconds to 5 is a three per cent improvement in exchange for a full rewrite. Fixing the query is a ninety per cent improvement in exchange for an afternoon.
What I actually choose, and why it is mostly not about speed
Node with TypeScript is my default, and the reason is not performance. It is that it is the same language as the front end, so types, validation logic and utilities are shared rather than reimplemented in two places and then kept in sync by hand forever. For I/O-bound work, which is most business software, the event loop is genuinely well suited to the shape of the problem — and note that the table above measures Express, not the faster runtimes now available in the same ecosystem.
Go is what I reach for when a service has to hold many thousands of concurrent connections cheaply, or when a single small binary with predictable memory is operationally valuable to whoever is on call.
Python earns its place wherever machine learning or data tooling is involved, because the libraries are there and nothing else is close, and the heavy numerical work is running in optimised native code anyway.
Java is the right answer when it is already the house stack and a team exists who can maintain it. That is not a consolation prize. It is usually the single strongest argument available.
Rust I recommend rarely and specifically: sustained CPU-bound throughput where the hosting bill scales with efficiency, so the efficiency is a line on the P&L rather than a preference.
When the language genuinely is the bottleneck
It does happen, and pretending otherwise is its own kind of dishonesty.
Real-time systems holding tens of thousands of persistent connections. Per-request CPU work like image or video transformation. High-frequency data ingestion. Workloads where compute cost is a material business number rather than a rounding error.
The tell is measurement, not intuition. If profiling shows the CPU saturated inside your own code rather than time spent waiting on other systems, the language matters and you should act on it. Otherwise you have a database, caching or architecture problem wearing a language problem's clothes, and the rewrite will cost a quarter and move nothing.
Perceived speed is a different number, and it is usually cheaper to buy
There is a category error buried in the original question that is worth naming, because it redirects a lot of wasted effort.
"Which backend is fastest" assumes the user is waiting on the backend. Frequently they are waiting on the front end waiting on the backend, which is not the same thing at all. A server-rendered page that shows content immediately and fills in data afterwards feels faster than a client-rendered page that shows a spinner while calling the identical API at the identical speed.
Same backend. Same response time. Different experience, and the second one is what generates the complaint that reaches the engineering team as "the API is slow".
I mention it because the fix is usually an order of magnitude cheaper than anything on the backend. Rendering the shell on the server, streaming the parts as they resolve, and being deliberate about which data actually has to arrive before the page is useful will beat a language migration on almost any project, and it can ship in a sprint.
Measure what the user waits for. It is often not what you think you are optimising.
Why Python stays on the list despite the numbers
Every version of this comparison puts Python near the bottom on throughput, and every version of this comparison is then contradicted by what teams actually build.
Two reasons, and both are real rather than inertia. For anything involving AI, data processing or scientific work, the library ecosystem has no serious competitor, and being able to use the tool that exists beats being able to run a tool you have to write. And the heavy numerical work is not running in the interpreter anyway — it is running in optimised native code that Python is orchestrating, which means the interpreter speed applies to the thin layer rather than to the work.
That is the general form of the argument and it applies more widely than Python. Interpreter or runtime speed matters in proportion to how much of the actual work happens there. For a service that spends its life marshalling JSON between a database and an HTTP response, that proportion is small, and the benchmark that measures it is measuring the least significant part of the job.
The criteria that beat raw speed
Who maintains this in three years, and can you hire them. How mature the libraries are for the specific integrations you need, not the ones in the tutorial. How fast a fix ships when something breaks at nine in the morning. What the hosting costs at your actual traffic rather than at 600,000 requests per second.
A stack that is four times slower on a synthetic benchmark and twice as fast to change is the better commercial choice for almost every business application anyone reading this is likely to build.
Fast enough is a real engineering target, and it is a better one than fastest. Define it — say, 200 milliseconds at the 95th percentile under expected load — write it down, and then pick the stack your team can keep meeting it with for years.
What to do now that the chart is gone
Benchmark your own workload, with your own data shape and your own query patterns. A synthetic hello-world throughput number has never predicted real application performance well, and its twelve-year run as the default answer to this question was always slightly accidental.
The honest version of "which backend is fastest" is that the question is answerable and almost never decisive.
Read the full version
This is the condensed version. The full article carries the complete Round 23 table with the hardware caveat in full, the per-stack notes on what each one is realistically good at, and the questions clients actually ask before a rewrite.
Which Backend Is Fastest? Go vs. Node vs. Java vs. Python
Sources
The throughput figures are from the final published round of the TechEmpower Framework Benchmarks, and the hardware change that lifted network-bound results is documented in TechEmpower's own Round 23 announcement. The 24 March 2026 archival, the stagnation criticisms and HttpArena as the proposed successor are recorded in this post here on DEV. Where the time actually goes on a business API is my own experience of profiling other people's.
If you have run a language rewrite specifically for performance, I would like to hear what the before-and-after actually looked like — particularly whether the profile said what you expected before you started.
Top comments (0)