When teams evaluate Spring Boot performance in 2026, the first question is almost always: "How fast does it start?" It's a tempting metric — easy to measure, quick to compare. But relying on startup time alone can lead to poor architectural choices. A reproducible lab shows that startup numbers hide critical differences in runtime behavior, especially for real-world applications. This Q&A breaks down why you need to look deeper.
1. Why is measuring only startup time a trap for architecture decisions?
Startup time gives a snapshot of how quickly an application becomes ready, but it ignores how the application performs once running. In production, latency under load, memory footprint, and throughput matter far more. The lab proves that a mode like native compilation may start faster but can show different (and sometimes worse) behavior on warm requests compared to JVM with CDS or AOT. Relying solely on startup numbers leads teams to choose technologies that optimize the wrong thing — the first five seconds instead of the next five hours of serving traffic.
2. What real application complexity does the lab use to avoid a false comparison?
Instead of a trivial "Hello World" endpoint that returns {"status":"ok"}, the lab backend includes concrete surface area: POST /api/orders with Jakarta Validation on a record, GET /api/orders/{id} using Spring Data JDBC on PostgreSQL 17, and a deterministic work endpoint POST /api/work that combines iterative CRC32 computation with a database query via countOrders(). It also uses Flyway for migrations, Actuator for readiness/liveness probes, and HikariCP with an explicitly configured pool. This design ensures the JIT has meaningful code to optimize and reveals real differences between modes.
3. What are the four startup modes compared in the lab?
The lab compares four distinct operational surfaces: jvm — standard java -jar on Eclipse Temurin 21, the baseline for most teams; cds — JVM with a dynamic AppCDS archive prepared in a separate phase; aot-jvm — Spring Boot AOT enabled on JVM with -Dspring.aot.enabled=true (verified in the container); and native — GraalVM Native Image compiled inside ghcr.io/graalvm/native-image-community:21. Each mode represents a realistic deployment option, and the benchmark tracks startup time, memory use, and warm latency.
4. How does the WorkService endpoint force real differences between modes?
The WorkService.calculateScore() method performs a deterministic loop of up to 5,000 iterations, mixing CRC32 computation with a golden Fibonacci constant and bit rotation. It also calls countOrders() to include a database interaction. Without this mix of CPU and I/O, the native and classic JVM modes look nearly identical on warm latency because the JIT has nothing interesting to optimize. The 5,000-iteration cap is validated by a unit test to keep the benchmark predictable and prevent accidental throughput testing. This endpoint is the key that exposes real runtime behavior differences.
5. What went wrong with the aot-jvm results during the benchmark run?
In the editorial run on May 17, 2026 (17:31–17:44 Buenos Aires time), the aot-jvm results initially made no sense — they appeared indistinguishable from the plain JVM baseline. The issue was that the flag spring.aot.enabled=true was not actually reaching the container environment. Once the team confirmed the flag was present and active in the runtime environment, the AOT mode produced different, meaningful numbers. This highlights a common pitfall: configuration errors can silently sabotage benchmarks, and verification of runtime flags is essential for reproducible results.
6. What should teams learn from this lab to avoid the startup time trap?
Teams should never base architecture decisions on startup time alone. The lab demonstrates that different deployment modes (JVM, CDS, AOT-JVM, native) each have trade-offs in startup speed, warm latency, memory consumption, and configuration complexity. Always measure a representative workload — not a skeleton endpoint — and include runtime metrics like p95 latency under realistic load. Verify that your configuration flags are actually enabled in production-like environments. Finally, consider the full lifecycle: a few seconds faster startup may not justify higher memory usage or slower warm performance for long-running services.