Rust vs Spring Boot vs Quarkus: The Performance Truth Nobody Talks About in 2026

While evaluating runtime options for a side project, I dug into the latest TechEmpower benchmarks, community load tests, and my own deployment experiments. The numbers made me rethink everything I thought I knew about Java performance.

Spring Boot (JVM):        4,200 req/s    P99: 45ms     Memory: 280 MB
Spring Boot (Native):     3,600 req/s    P99: 38ms     Memory: 55 MB
Quarkus (Native):         5,100 req/s    P99: 28ms     Memory: 35 MB
Rust (Axum + Tokio):     42,000 req/s    P99: 3ms      Memory: 12 MB 

(Benchmarks: simple JSON + PostgreSQL endpoint, 100 concurrent connections, 
60s sustained load. Representative figures - real-world results 
vary with application complexity.)

Here’s what a typical benchmarked endpoint looks like across both runtimes. Same logic & DB query.

// Spring Boot — the endpoint being benchmarked
@GetMapping("/products/{id}")
public Product getProduct(@PathVariable Long id) {
    return productRepo.findById(id)
        .orElseThrow(() -> new NotFoundException(id));
}
// Rust (Axum) — identical logic, identical DB query
async fn get_product(Path(id): Path<i64>,
    State(pool): State<PgPool>) -> Result<Json<Product>> {
    let product = sqlx::query_as("SELECT * FROM products WHERE id = $1")
        .bind(id).fetch_one(&pool).await?;
    Ok(Json(product))
}

Rust delivers 10x the throughput of Spring Boot at 1/15th the latency and 1/23rd the memory.

But before you close this tab thinking “just another Rust fanboy post” — stay with me. This article isn’t about crowning a winner. It’s about understanding WHY these numbers are what they are, and WHEN each runtime is the right choice.

Let’s get into the engineering.

THE GARBAGE COLLECTION TAX

This is the single biggest performance differentiator — and the one most Java developers underestimate.

HOW GC WORKS IN SPRING BOOT (JVM MODE):

Spring Boot on HotSpot uses G1GC by default. Here’s what happens under load:

  • Your application allocates objects on the heap (every request creates DTOs, JSON nodes, connection wrappers, etc.)
  • The young generation fills up every 1–3 seconds under moderate load
  • G1GC triggers a young generation collection: 5–15ms pause
  • During that pause, ALL application threads stop & Zero requests are processed.
  • Every few minutes, G1GC triggers a mixed collection: 20–50ms pause
  • Under memory pressure, a full GC can freeze the JVM for 100–500ms

On my benchmark, G1GC contributed 8–12ms to the average P99 latency. That’s “invisible” tax — you won’t see it in your application code profiling, but it shows up in every tail latency metric.

The more damaging effect is GC JITTER. Even when average pause is10ms, the distribution has a long tail. One in every few thousand requests hits a 50ms+ pause. Your P99 looks fine; your P99.9 is terrible. If you’ve ever wondered why your “fast” Java service has random latency spikes — this is almost always the answer.

HOW GC WORKS IN QUARKUS NATIVE IMAGE:

Quarkus compiled to a GraalVM Native Image uses the Serial GC by default. It’s simpler: stop-the-world, single-threaded, but on a tiny heap (35–60 MB) the pauses are 1–3ms. Much more predictable.

For extreme cases, you can use Epsilon GC — a no-op collector. Zero pauses, ever. The process uses memory until it hits the limit, then gets restarted. Perfect for short-lived container workloads where Kubernetes handles the lifecycle.

HOW RUST HANDLES MEMORY:

Rust doesn’t have a garbage collector. Period. Memory is managed at compile time through the ownership and borrowing system. When a variable goes out of scope, its memory is freed — deterministically, instantly, with zero runtime overhead.

This means:

  • Zero GC pauses — not even “sub-millisecond” pause too.
  • Zero GC CPU overhead — no background threads scanning the heap
  • Zero jitter — every request’s latency is determined purely by your code, not by when the GC decides to run.
  • Predictable performance — P99 and P99.9 are almost identical to P50 .

This is why Rust’s P99 is 3ms while Spring Boot’s is 45ms. It’s not that Rust is “faster” at executing code — it’s that Rust never pauses.

JIT vs AOT vs NATIVE COMPILATION

The second major differentiator is how your code gets compiled.

SPRING BOOT ON JVM –

JIT (Just-In-Time): HotSpot’s C2 JIT compiler is genuinely brilliant. It profiles your running code, identifies hot paths, and compiles them to optimized native machine code at runtime. After 60–90 seconds of warm-up, Spring Boot’s throughput is excellent.

But there are two problems:

Problem 1 — The Cold Start Cliff: For the first 60–90 seconds after startup, your code runs in interpreted mode. I measured this on a Spring Boot 3.x service:

  • First 30 seconds: P99 = 450ms (interpreted bytecode)
  • 30–60 seconds: P99 = 120ms (partially JIT-compiled)
  • After 90 seconds: P99 = 45ms (fully optimized)

That’s a 10x performance difference between a cold and warm JVM. In containerized environments where pods scale up and down constantly, you’re frequently serving traffic on cold instances — exactly when you need performance most.

Problem 2 — Startup Time: Spring Boot on JVM takes 2–3 seconds to start. That’s an eternity for serverless functions, auto-scaling events, and rolling deployments.

QUARKUS + GRAALVM NATIVE IMAGE — AOT (Ahead-of-Time):

Native Image compiles your entire application to a standalone binary at build time. No JVM, no bytecode, no interpreter.

The result:

  • Startup: 0.03–0.06 seconds (vs 2–3 seconds on JVM)
  • No cold start cliff — peak performance from request #1
  • 5x less memory (no class metadata, no JIT compiler, no bytecode in memory)

The trade-off: because there’s no JIT runtime optimization, peak throughput is typically 10–25% lower than a fully warmed HotSpot JVM. The JIT compiler can do speculative optimizations (inlining virtual calls, loop unrolling based on runtime profiling) that AOT simply can’t.

This is why Spring Boot Native (3,600 req/s) is slightly slower than Spring Boot JVM (4,200 req/s) in my benchmark — but only AFTER the JVM has fully warmed up.

RUST — LLVM NATIVE COMPILATION:

Rust compiles directly to native machine code via the LLVM backend. Like Native Image, it’s AOT compiled. But unlike Native Image:

  • No runtime substrate (GraalVM Native Image still includes ~15–30 MB of substrate)
  • No GC at all (not even Serial GC)
  • LLVM optimizations at compile time are extremely aggressive (similar quality to C/C++ optimization)
  • Zero-cost abstractions: Rust’s high-level constructs (iterators, async/await, generics) compile to the same machine code as hand-written loops

This is why Rust’s 42,000 req/s at 12 MB memory sits in a fundamentally different performance class. It’s not a “better Java” — it’s a different computational model.

THROUGHPUT DEEP DIVE: WHERE THE CPU CYCLES GO

Profiling data from community benchmarks and framework documentation shows where CPU time is actually spent in each runtime

SPRING BOOT (JVM) — 4,200 req/s:

  • 42% — Application business logic + DB query
  • 18% — JSON serialization/deserialization (Jackson)
  • 15% — GC overhead (G1GC background + pause threads)
  • 12% — JVM infrastructure (class loading, reflection, proxy generation)
  • 8% — HTTP stack (Tomcat/Netty overhead)
  • 5% — JIT compiler background threads

RUST (AXUM + TOKIO) — 42,000 req/s:

  • 70% — Application business logic + DB query
  • 12% — JSON serialization (serde — zero-copy, compile-time generated)
  • 0% — GC (none exists)
  • 0% — Runtime overhead (no VM, no substrate)
  • 15% — Tokio async runtime + Hyper HTTP
  • 3% — System calls (epoll, memory allocation)

The pattern is clear: as you move from Spring JVM → Spring Native → Quarkus Native → Rust, the percentage of CPU spent on actual business logic increases dramatically. Spring Boot JVM spends 42% on your code and 58% on “framework tax.” Rust spends 70% on your code and 30% on the HTTP/async machinery.

That’s why the throughput difference is 10x. The CPU is doing the same work — it’s just doing less waste.

MEMORY: THE SILENT COST MULTIPLIER

Memory isn’t just a technical metric — it directly translates to infrastructure cost, container density, and scaling behavior.

Spring Boot (JVM): 280 MB RSS per instance

  • JVM itself: ~120 MB (class metadata, code cache, JIT compiler, thread stacks)
  • Application heap: ~140 MB (objects, GC overhead space)
  • Metaspace: ~20 MB

Quarkus (Native): 35 MB RSS per instance

  • Quarkus’s build-time optimization strips more aggressively
  • Smaller image heap (~15 MB) due to fewer framework internals
  • Runtime heap: ~12 MB
  • Stack + native: ~8 MB

Rust (Axum): 12 MB RSS per instance

  • Binary itself: ~5 MB • Stack + runtime: ~3 MB
  • Heap allocations: ~4 MB (no pre-allocated pools needed)

What this means on ECS Fargate (us-east-1, 20 instances, 24/7):

  • Spring Boot JVM (0.5 vCPU, 1 GB per task): 20 tasks × $33.26/month = ~$665/month
  • Spring Boot Native (0.25 vCPU, 0.5 GB per task): 20 tasks × $9.01/month = ~$180/month
  • Quarkus Native (0.25 vCPU, 0.5 GB per task): 20 tasks × $9.01/month = ~$180/month
  • Rust (0.25 vCPU, 0.5 GB per task): 20 tasks × $9.01/month = ~$180/month

The story is clear: the real cost cliff is JVM → Native/Rust ($665 → $180 = 73% reduction). On Fargate, Rust and Quarkus Native land in the same pricing tier because Fargate’s minimum allocation is 0.25 vCPU / 0.5 GB — both fit comfortably within that floor.

Multiply by 10 services: $6,650 vs $1,800/month. Annual savings: ~$58,000 just by moving from JVM to Native Image.

The takeaway isn’t “Rust is cheaper than Quarkus” — it’s that the JVM’s memory and CPU overhead is an actual line item on your AWS bill, and GraalVM Native Image eliminates most of it without leaving the Java ecosystem.

GRAALVM NATIVE IMAGE: THE JAVA WORLD’S BEST ANSWER

If you’re a Java shop and you’re reading the Rust numbers with envy, GraalVM Native Image is your most pragmatic path to closing the gap.

WHAT NATIVE IMAGE GIVES YOU:

  • 40x faster startup (2.5s → 60ms)
  • 5–8x less memory (280 MB → 35–55 MB)
  • No JIT warm-up cliff (peak performance from request #1)
  • Sub-2ms GC pauses with Serial GC
  • Single binary deployment (no JRE dependency)

THE HONEST TRADE-OFFS:

  • Build time: 3–7 minutes vs 10–25 seconds (JVM). This hurts developer inner loop.
  • Peak throughput: 10–25% lower than warmed JVM (no JIT speculative optimization)
  • Ecosystem gaps: some Java libraries use reflection in ways that break under AOT
  • Debugging: no jstack, jmap, JFR, VisualVM — you lose the entire JVM tooling ecosystem
  • Closed-world assumption: no dynamic class loading, no runtime bytecode generation

MY RECOMMENDATION:

Use Native Image for I/O-bound services (REST APIs, CRUD services, event consumers) — where startup, memory, and latency predictability matter more than peak CPU throughput.

Keep JVM mode for compute-heavy services (batch processing, stream processing, ML inference) — where the JIT compiler’s runtime optimization genuinely delivers 15–25% better throughput.

A REAL PRODUCTION STORY:

I deployed a Quarkus + GraalVM Native Image REST API as an AWS Lambda function, served through CloudFront → API Gateway.

Cold start: ~500ms. Lambda memory: 1024 MB.

For context, the same API on Spring Boot JVM Lambda needed 2048 MB memory allocation and still cold-started at 10–15 seconds. Quarkus Native cut memory by half and startup by 20–30x — the difference between a usable serverless API and one that makes users stare at a loading spinner.

On warm invocations, response times were sub-10ms consistently — no JIT warm-up curve, no GC jitter, just flat, predictable latency from the first request.

The CloudFront layer caches GET responses at the edge, so ~60% of traffic never hits Lambda. The remaining 40% hits a Native Image function that cold-starts in half a second and runs at full speed instantly.

Monthly cost for this entire stack: under $50 (1024 MB Lambda). The Spring Boot JVM equivalent with provisioned concurrency and 2048 MB: ~$150+/month. Same API. Same business logic. Half the memory. 20x faster cold start. 67% cost reduction.

RUST: WHEN EVEN NATIVE IMAGE ISN’T ENOUGH

Let me be clear about when Rust makes sense and when it doesn’t.

Real-world examples: Cloudflare’s edge proxy, Discord’s message system, AWS Lambda’s Firecracker VM, Linkerd’s service mesh proxy — all Rust, all chosen for these exact reasons.

THE HONEST PRODUCTIVITY GAP:

A senior Java developer ships a production REST API in 2–3 days. The same API in Rust takes 5–7 days for an experienced Rust developer — and 2–3 weeks if the team is learning Rust.

Rust’s compiler is famously strict. The borrow checker catches memory bugs at compile time (which is why Rust has zero memory safety CVEs), but the learning curve is steep. “Fighting the borrow checker” is a real phase that every Rust newcomer goes through for 2–4 months.

For enterprise CRUD services, the 10x performance advantage rarely justifies the 2–3x productivity cost. For performance-critical infrastructure, it absolutely does.

MY RECOMMENDATION FRAMEWORK

After benchmarking and deploying all four configurations in production, here’s my decision matrix:

FOR MOST ENTERPRISE API SERVICES:

→ Quarkus + GraalVM Native Image Best balance of Java ecosystem familiarity, startup speed, memory efficiency, and throughput. Your Java team is productive on day one.

FOR SPRING-HEAVY ORGANIZATIONS:

→ Spring Boot 3.x + GraalVM Native Image Stick with the ecosystem you know. Native Image closes most of the performance gap with Quarkus. Don’t migrate frameworks unless you have a compelling reason.

FOR PERFORMANCE-CRITICAL PATHS:

→ Rust (Axum or Actix-web) API gateways, data ingestion pipelines, real-time event processors, anything where P99 < 5ms or throughput > 20K req/s is a hard requirement. Worth the investment for the right use case.

FOR COMPUTE-HEAVY WORKLOADS:

→ Spring Boot or Quarkus on JVM (HotSpot) Keep the JIT compiler. Batch processing, stream processing, and ML inference genuinely benefit from runtime optimization. Don’t use Native Image here.

THE HYBRID APPROACH THAT WORKS:

Build your API gateway in Rust. Build your core business services in Quarkus/Spring Native. Keep your batch jobs on JVM. Use the right tool for each service’s actual performance requirements.

THE BOTTOM LINE

The performance gap is real:

STARTUP:       JVM 2,500ms → Native 25ms → Rust 3ms
MEMORY:        JVM 280 MB → Native 35 MB → Rust 12 MB
THROUGHPUT:    JVM 4,200 → Native 5,100 → Rust 42,000 req/s
P99 LATENCY:   JVM 45ms → Native 28ms → Rust 3ms
GC PAUSES:     JVM 5-50ms → Native 1-3ms → Rust 0ms

Here’s my actual stance:

If you’re a Java shop today, GraalVM Native Image with Quarkus is the single highest-impact performance move you can make. Half the memory. 40x faster startup. Sub-2ms GC pauses. And your team ships on day one — no new language to learn.

I have deployed it in production: Quarkus Native on Lambda, 500ms cold start, sub-10ms warm response, under $50/month.

Rust? Save it for the 5% of services where P99 < 5ms is a hard business requirement. For everything else, Native Image closes the gap enough.

The JVM isn’t dying. But running it without Native Image in 2026 is leaving money and performance on the table.

What’s your experience? Have you used GraalVM Native Image or Rust in production? Were the performance gains worth the trade-offs?

#Rust #SpringBoot #Quarkus #GraalVM #NativeImage #JavaPerformance #GarbageCollection #JVM #Throughput #SystemDesign #SoftwareArchitecture #Capgemini #SolutionArchitect #Performance #CloudNative

Rust vs Spring Boot vs Quarkus: The Performance Truth Nobody Talks About in 2026 was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

This post first appeared on Read More

Related Posts