When should you use Quarkus over a traditional Spring application?

Quarkus tends to be the stronger fit specifically when startup time, memory footprint, or native-image deployment are decision-driving requirements, rather than in every microservice scenario universally.

• Serverless / FaaS deployments: cold-start latency directly affects cost and user-perceived latency, where Quarkus's native mode has a clear edge.
• High-density container deployments: running many instances per node where lower per-instance memory usage translates directly into infrastructure savings.
• Greenfield cloud-native services: no existing investment in Spring-specific libraries, so there's less migration friction to weigh against Quarkus's benefits.
• Reactive, I/O-heavy workloads: services that benefit from Quarkus's tight, Vert.x-based reactive integration out of the box.

Conversely, a team with a large existing Spring codebase, deep reliance on Spring-specific libraries without direct Quarkus equivalents, or no strong startup/footprint constraint often has little concrete reason to migrate — the decision should follow measured requirements (actual cold-start SLAs, actual memory budgets) rather than choosing a framework purely because it's newer or benchmarks faster in isolation.