DEV Community: Volodymyr Diachenko

Apollo vs Mercurius vs Yoga: I Benchmarked 10 Node.js GraphQL Setups (With and Without NestJS)

Volodymyr Diachenko — Wed, 14 Oct 2026 13:00:00 +0000

Choosing a GraphQL server for Node.js? I benchmarked Apollo, Mercurius and Yoga on Express, Fastify and plain node:http, each with and without NestJS: 10 setups, same schema, same queries.

This is a follow-up to my NestJS GraphQL benchmark (Express vs Fastify, Apollo vs Mercurius). The most common question there was: "How much does NestJS itself cost? What if I drop it?" So this time I added:

NestJS + GraphQL Yoga
The same stacks without NestJS: Express + Apollo, Fastify + Apollo, Fastify + Mercurius, Fastify + Yoga
Yoga on Express and Yoga standalone on plain node:http

…and re-ran everything.

TL;DR

The GraphQL engine matters most. Mercurius did 1.3–1.8× the throughput of Apollo in every query scenario, with about half the p99 latency on nested queries. Yoga landed in between on real queries.
The HTTP framework matters mostly for tiny queries. With Apollo, Fastify beat Express by 18–29% on health but only ~3% on deep-nested. For Yoga, standalone, Express and Fastify were within a few percent on real queries.
NestJS adds no measurable overhead. Each NestJS server is within −6% to +5% of the same stack without it, and which one wins flips from scenario to scenario.
Mutations are the same everywhere (~9,000–9,400 req/s).

📊 Interactive dashboard: https://gql-bench.vercel.app/
💻 Code (run it yourself): https://github.com/vovadyach/gql-bench

What was tested

Every server implements the same schema, data and resolvers. Only the stack changes.

NestJS 10	Direct (no NestJS)
Express + Apollo	Express + Apollo
Fastify + Apollo	Fastify + Apollo
Fastify + Mercurius	Fastify + Mercurius
Fastify + Yoga	Fastify + Yoga
	Express + Yoga
	Yoga standalone (`node:http`)

Scenarios:

Scenario	What it is
`health`	Tiny query: pure framework + GraphQL engine overhead
`single-user`	1 user + posts + comments
`user-list`	10 users, nested
`deep-nested`	5 × 10 × 8 nested objects + some CPU work (~90 KB responses)
`mutation`	Write with body parsing
Mixed traffic	Production-like query mix: 30% health, 25% single-user, 20% mutation, 15% user-list, 10% deep-nested

Results

Requests per second, median of 3 full runs (higher is better):

Server	health	single-user	user-list	deep-nested	mutation	mixed
NestJS Fastify + Mercurius	30,631	13,047	4,397	902	9,065	6,862
Direct Fastify + Mercurius	29,489	12,889	4,226	887	9,004	6,769
Direct Yoga standalone	20,994	11,050	3,562	731	9,072	5,436
Direct Express + Yoga	19,575	11,109	3,625	730	9,162	5,388
Direct Fastify + Yoga	17,854	10,525	3,548	731	8,988	5,214
NestJS Fastify + Yoga	16,966	10,084	3,533	753	8,984	5,151
NestJS Fastify + Apollo	21,937	10,191	2,831	493	9,444	3,974
Direct Fastify + Apollo	21,075	9,560	2,781	484	9,423	4,055
NestJS Express + Apollo	17,032	9,080	2,703	480	9,378	3,706
Direct Express + Apollo	17,856	9,036	2,706	472	9,145	3,832

p99 latency on deep-nested: 68 ms for Mercurius vs 123 ms for Fastify + Apollo.

NestJS vs direct, pair by pair

Throughput of the direct version relative to the NestJS version:

Pair	health	single-user	user-list	deep-nested	mutation	mixed
Express + Apollo	+4.8%	−0.5%	+0.1%	−1.8%	−2.5%	+3.4%
Fastify + Apollo	−3.9%	−6.2%	−1.8%	−1.9%	−0.2%	+2.0%
Fastify + Mercurius	−3.7%	−1.2%	−3.9%	−1.6%	−0.7%	−1.4%
Fastify + Yoga	+5.2%	+4.4%	+0.4%	−3.0%	0.0%	+1.2%

No consistent winner. NestJS adds dependency injection and a resolver layer, but once a request reaches the GraphQL engine, that layer costs about as much as run-to-run noise.

Methodology

Apple M1 Max, Node.js 24, single process per server, one server at a time
k6, ramping to 50 virtual users, 30 s sustained load per scenario
3,000 warmup requests per server (discarded), 5 s cooldown between servers
Every GraphQL response validated; response sizes verified identical across servers
All runs passed thresholds (<1% HTTP failures, <1% GraphQL errors)
3 full runs, median reported

Limits: in-memory data (no database), one machine, single process. Absolute numbers will differ on your hardware; the ratios between servers are the useful part. With a real database, these differences shrink because I/O dominates.

So what should you use?

Not using NestJS?

Fastest: Fastify + Mercurius, in every query scenario.
Like Yoga? Its HTTP layer barely matters on real queries: standalone, on Express or on Fastify all landed within a few percent.
On Apollo? Prefer Fastify over Express for light queries, and expect Apollo to fall behind as queries get more nested.

Using NestJS?

Need more throughput? Switch the driver to @nestjs/mercurius on Fastify; it gave the biggest gain in every query scenario.

I Benchmarked NestJS GraphQL: Express vs Fastify vs Mercurius — Here's What Actually Won

Volodymyr Diachenko — Mon, 16 Mar 2026 03:24:05 +0000

TL;DR: Under sustained load, Mercurius is the clear winner, outperforming the other setups by 60–89% across all tested scenarios. But low-concurrency benchmarks tell a different story. The “best” choice depends heavily on how you test.

Live Dashboard | GitHub

The Setup

I benchmarked three NestJS GraphQL server configurations using the same schema, resolvers, and in-memory data generators. The only differences were the HTTP transport and GraphQL engine.

Server	HTTP Transport	GraphQL Engine
Express + Apollo	`@nestjs/platform-express`	Apollo Server 4
Fastify + Apollo	`@nestjs/platform-fastify`	Apollo Server 4
Fastify + Mercurius	`@nestjs/platform-fastify`	Mercurius 14

All tests were run with k6 in sequential mode — one server at a time, using the full machine. Each run included 500 warmup requests, and every GraphQL response was validated.

I used two benchmark profiles:

Quick: 10 VUs, ~3 minutes
Standard: 50 VUs, ~20 minutes

Standard Results (50 VUs)

                        Express      Fastify        Mercurius
Health (light):         6,491        8,729 (+34%)   12,238 (+89%)
Single User (medium):   4,328        5,128 (+18%)    7,772 (+80%)
Paginated (heavy):      1,423        1,501  (+6%)    2,549 (+79%)
Deep Nested (extreme):    267          272  (+2%)      496 (+86%)
Mutation (medium):      5,598        7,000 (+25%)    8,930 (+60%)

Mercurius came out on top in every scenario.

The most interesting result was not that Mercurius won — it was how little Fastify + Apollo improved over Express on heavy queries. In the more expensive scenarios, the gap was only around 2–6%, much smaller than I expected.

The Interesting Part: Quick vs Standard

Same code, same machine, different load profile — different results:

Mutation (quick, 10 VUs):    Mercurius +2%    (barely wins)
Mutation (standard, 50 VUs): Mercurius +60%   (dominates)

Mercurius scales better as concurrency increases. A low-concurrency benchmark doesn’t tell the full story.

Reality Check

These benchmarks focus on framework overhead, not full application behavior.

There’s no database, no Redis, no external API calls, and no network latency. Everything runs against in-memory data so the comparison isolates the framework stack as much as possible.

In a real application, resolvers often spend most of their time elsewhere:

PostgreSQL queries: +5–50ms
external API calls: +50–200ms
uncached or complex operations: often much more

In that context, framework overhead may be only a small fraction of total latency.

So while framework choice does matter, it matters most when:

your app is already well optimized
throughput at scale is important
framework overhead is one of the remaining bottlenecks

If your API feels slow today, your first win probably won’t come from switching frameworks. It will usually come from fixing query design, eliminating N+1 problems with DataLoader, improving caching, or reducing database and external API latency.

Recommendation

Mercurius — if you want the best throughput and p99 latency under load. In these tests, it was the clear winner.

Express + Apollo — if you want the most familiar ecosystem or are optimizing for compatibility and fast prototyping.

Fastify + Apollo — if you need Apollo-specific features like federation and still want a moderate boost over Express (+6–34%).

Try It Yourself

git clone https://github.com/vovadyach/gql-bench
cd gql-bench
npm run setup           # ~20 min
npm run bench:quick     # ~3 min

Or explore the Live Dashboard — toggle frameworks, switch profiles, dive into scenarios.

What's Next

I’m extending this benchmark beyond Node.js to compare Go, C#, and Java against the same workload.

The NestJS results were already interesting. The cross-language comparison should be even more revealing.

Follow the repo if you want to see the next round of results.

Built with k6, NestJS 10, Apollo Server 4, Mercurius 14. Dashboard: Next.js + shadcn/ui + Recharts.