Cold starts used to make Java a punchline in the serverless world. That punchline is running out of material.
For years, the serverless conversation went like this: Python or Node.js for functions, Java for the big services running behind them. The reason was simple — a Java Lambda function on AWS could take anywhere from 5 to 10 seconds to cold start. In a world where users abandon pages that take more than 3 seconds to load, that’s not a tradeoff, it’s a dealbreaker.
But the tools have caught up. Between AWS Lambda SnapStart, GraalVM native compilation, and cloud-native frameworks like Quarkus and Micronaut, the story has genuinely changed. The serverless market is valued at $25.25 billion in 2025 and growing fast — Java developers who dismiss it are leaving a large table.
This article walks through the three main paths available to Java developers today, where each one wins and where it hurts, and whether the economics finally make sense.
1. The Cold Start Problem — A Brief History
Cold starts happen when the cloud provider has to spin up a new execution environment for your function. For interpreted languages like Python and Node.js, this is largely a matter of loading the runtime and your code — typically 100–400ms. For Java, it historically meant loading the JVM, initializing the class loader, bootstrapping the framework (Spring Boot especially loves doing a lot of work here), and only then starting your actual code.
The result? 3–10 seconds of dead time before a user gets a response. For background tasks, that’s annoying. For user-facing APIs, it’s unacceptable. The community responded with workarounds — “keep-warm” EventBridge pings, provisioned concurrency — but these either cost money whether you need them or not, or they just barely paper over the issue.
“Java cold starts aren’t just a performance issue. At scale, INIT phase billing means cold starts can represent 50%+ of your Lambda compute costs for high-traffic Java functions.”— AWS Lambda Cold Starts in 2025, Edge Delta
That’s the context. Now let’s look at what’s actually changed.
Cold Start Times by Runtime — Before vs. After Optimization
2. AWS Lambda SnapStart: The Pragmatic Fix
SnapStart is AWS’s infrastructure-level answer to Java cold starts, and as of 2025–2026 it’s the lowest-effort, highest-impact option available. When you publish a function version with SnapStart enabled, Lambda fully initializes your function, takes a Firecracker microVM snapshot of the complete memory and disk state, encrypts it, and caches it across availability zones. Instead of re-initializing from scratch on every cold start, Lambda simply restores from that snapshot.
The numbers are striking. Without SnapStart, production Spring Boot functions show P50 cold starts around 3,841ms and P99 around 5,200ms. With SnapStart optimized, P50 drops to 182ms and P99 to 700ms — a 95% reduction at the median. That brings Java into direct competition with Python and Node.js for most use cases.
AWS extended SnapStart support to Python 3.12+ and .NET 8 in late 2024, and Java 25 support arrived in November 2025 — with a notable improvement: Lambda no longer stops tiered JIT compilation at the C1 tier for SnapStart and Provisioned Concurrency functions. That means compute-heavy Java functions now get the full benefit of JIT optimization without the cold start penalty.
2.1 SnapStart’s catch: stateful initialization
SnapStart isn’t magic. Since a single snapshot is used as the base for multiple execution environments, anything your initialization code generates — random IDs, cryptographic seeds, database connections — gets “frozen” into that snapshot. TCP connections established during INIT will be dead by the time the function is restored from snapshot. Any entropy used to seed random number generators must be regenerated post-restore.
AWS provides CRaC (Coordinated Restore at Checkpoint) hooks — beforeCheckpoint() and afterRestore() — to handle this. But it requires awareness. Teams migrating existing Spring Boot applications should audit initialization code carefully before enabling SnapStart.
Quick rule of thumb: If your Lambda function is Java 11 or later, enable SnapStart on published versions. It’s free, requires minimal code changes for most functions, and delivers 90%+ cold start reductions. If you use random IDs or DB connections in your INIT phase, add the CRaC restore hooks.
3. GraalVM Native Image: Surgical, Powerful, Demanding
Where SnapStart works around the JVM startup problem, GraalVM eliminates it entirely. Ahead-of-time (AOT) compilation turns your Java application into a native binary — no JVM required at runtime. The result starts in tens of milliseconds and uses a fraction of the memory.
The benchmark data from Liberty Mutual’s production experience is compelling: a Spring Boot function that took 5.7 seconds to cold start dropped to 655ms as a native image — roughly a 9x improvement. Once warm, that same function ran with a billed duration of just 20ms using 160MB of memory. Benchmarks consistently show native images using 4x less memory than a standard JVM for equivalent workloads. For Lambda, where you pay for both memory and duration, that’s direct cost savings on two axes at once.
Micronaut takes this further still. Because it resolves dependency injection at compile time rather than via reflection, native-compiled Micronaut applications start in 30–50ms with memory usage in the 30–40MB range. That’s not just competitive with Python — it’s faster than most interpreted runtimes.
3.1 The real cost: build complexity
GraalVM’s “closed-world assumption” is both its strength and its constraint. At build time, the native-image compiler performs deep static analysis to determine every class reachable from the main entry point. Anything it can’t prove is reachable gets excluded. That means dynamic class loading, reflection-heavy frameworks, and runtime-generated proxies need explicit configuration — or they break in production.
Spring Boot improved dramatically with version 3.0’s native compilation support, but Spring’s heavy reliance on reflection still requires careful configuration. Build times are significantly longer (often 5–15 minutes for a full native image). And native binaries are platform-specific — you need to build in the target environment (typically a Linux container) for Lambda deployment.
Trade-off to know: A warm JVM with full JIT optimization will outperform a native image for CPU-intensive, long-running workloads. Native images are optimized for startup and IO-bound tasks — which is exactly what most serverless functions are. For batch processing or compute-heavy functions, benchmark both before committing.
4. Azure Functions: The Honest Picture
Azure Functions supports Java, but its story is less optimistic than AWS’s. Microsoft has invested seriously in cold start optimization — running roughly 85,000 cold start samples daily across all regions to benchmark and tune the platform. The new Flex Consumption plan reduces cold starts through “always ready” instances and faster pre-warming algorithms.
But Java on Azure Functions still lags. An independent November 2025 benchmark found Java performance “on par with Python” on the Flex Consumption plan — meaning the JVM overhead is still visible. C# and Node.js start noticeably faster. Azure doesn’t offer a SnapStart equivalent for Java, and GraalVM native images require custom runtime configuration that adds complexity without Microsoft-first tooling support.
If your stack is Azure-native — using Azure Service Bus, Cosmos DB, and the Microsoft ecosystem — Java Functions still makes sense for event-driven workloads where cold starts are less critical (queue processing, scheduled jobs). For latency-sensitive HTTP APIs on Azure, the honest answer is that C# with AOT compilation or Node.js currently offers a better serverless experience.
Cold Start Latency Comparison Across Platforms (P50, ms)
5. The Framework Dimension: Quarkus, Micronaut, and Spring
Your choice of Java framework matters as much as your cloud platform in serverless contexts. Quarkus and Micronaut were designed with compile-time optimization as a first-class concern — they both produce native images more reliably than Spring, with better integration for Lambda-specific event models.
| Framework | Cold Start (JVM + SnapStart) | Cold Start (Native) | Memory (Native) | DX / Ecosystem |
|---|---|---|---|---|
| Spring Boot 3.x | 200–500ms | 600–750ms | ~120–160MB | Excellent — huge ecosystem, most familiar |
| Quarkus | 100–250ms | ~50–150ms | ~50–80MB | Strong — built for cloud-native, great AWS extensions |
| Micronaut | 80–200ms | 30–60ms | 30–40MB | Good — fastest startup, compile-time DI, smaller community |
| Plain Java (AWS SDK v2) | 100–300ms | ~50ms | ~25–40MB | Maximum control, minimal abstraction, high boilerplate |
Spring Boot’s native image support has improved substantially with Spring Boot 3+ and Spring Cloud Function’s AWS adapter, but it still produces slightly slower cold starts than Quarkus or Micronaut at the native level. For teams already deep in Spring’s ecosystem, SnapStart with priming is probably the pragmatic path. For greenfield serverless Java, Quarkus has the best combination of developer experience and performance.
6. Does the Economics Make Sense?
Let’s be concrete. Lambda pricing is based on memory allocated multiplied by execution duration in milliseconds. A function that cold-starts in 4 seconds vs 200ms doesn’t just feel faster — it bills differently. Specifically, AWS bills the INIT phase separately, which means cold starts for high-traffic Java functions without SnapStart can represent a substantial portion of your bill.
A 1GB function with 100,000 cold starts costs roughly $18/month in INIT phase billing alone. At scale, with optimized Java (SnapStart + reduced initialization), that cost largely disappears. GraalVM native images go further — lower memory allocation (say, 256MB instead of 512MB) plus shorter execution time means you’re paying significantly less per invocation at both axes simultaneously.
Node.js and Python still have an advantage for teams without existing Java codebases, where the operational simplicity and faster iteration cycles matter. But for enterprise teams with significant Java investment — existing business logic, team expertise, shared libraries — the cost of maintaining two language stacks is real. The performance gap has narrowed enough that keeping serverless in Java is now a defensible architectural choice, not a compromise.
Node.js and Python still have an advantage for teams without existing Java codebases, where the operational simplicity and faster iteration cycles matter. But for enterprise teams with significant Java investment — existing business logic, team expertise, shared libraries — the cost of maintaining two language stacks is real. The performance gap has narrowed enough that keeping serverless in Java is now a defensible architectural choice, not a compromise.
7. When to Use Java for Serverless in 2026
The honest answer is: it depends on your use case, but the conditions for “yes” have expanded considerably. Here’s how to think through it.
// Decision heuristic — not actual code, but a mental model
// Prefer Java serverless when: // - You have existing Java business logic worth reusing // - Functions are high-throughput (warm JVM advantage kicks in) // - Type safety and tooling matter (complex domain models) // - Cold starts < 500ms is acceptable (use SnapStart) // - You can invest in GraalVM config for sub-100ms starts // Prefer Node.js / Python when: // - Greenfield, small team, fast iteration is the priority // - Functions are rarely invoked (cold starts are frequent) // - Azure Functions is your platform (Java still lags here) // - Serverless is glue code, not core business logic
The sweet spot for Java serverless in 2026 is exactly where Java has always been strong: complex domain logic, rich type systems, shared enterprise libraries, and applications where the investment in GraalVM or SnapStart configuration pays back across many functions. It’s not the right tool for quick webhook handlers or simple API glue — Python or Node.js still win there on pure developer velocity.
8. What We’ve Learned
Serverless Java has crossed a meaningful threshold. AWS Lambda SnapStart can reduce cold starts by up to 95% at P50 — from over 3,800ms to under 200ms — at zero additional cost and with minimal code changes. GraalVM native images go further, producing binaries that start in under 100ms and use 4x less memory than JVM equivalents, with frameworks like Quarkus and Micronaut making the path more reliable than it was even a year ago.
Azure Functions remains a weaker story for Java: without a SnapStart equivalent and with Java cold starts still running on par with Python, teams on Azure should reserve Java for async, non-latency-sensitive workloads or invest in custom native runtime configurations.
Economically, the case has closed for most enterprise teams. The performance gap with Node.js and Python is no longer prohibitive — it’s manageable. Java’s advantages in type safety, tooling, and existing enterprise codebase don’t disappear just because a function is serverless. With the right framework and deployment strategy, serverless Java in 2026 is a legitimate first-class option, not a reluctant compromise.
