Hello. I'm not sure comparing graalvm native in one technology to jvm of another technology is a fair comparison. You would see reduced throughput numbers if you were comparing spring native to spring jvm.
If I were trying to figure out "jvm vs native" it might be better to stick to the same technology stack & versions of things - that way you are only changing 1 variable (i.e. spring jvm vs spring native, quarkus jvm vs quarkus native).
The better comparison would be to compare jvm of one technology to another. The Quarkus team has recently open sourced all of its benchmarks and comparisons: github.com/quarkusio/benchmarks
Understood, but your statement "To optimize costs while maintaining performance, I started exploring alternatives within the Java ecosystem." implies that Quarkus on the JVM is not a viable solution?
While I'm happy you are exploring Quarkus (yay!) I just want to be clear that native compilation in general (regardless of framework) has a small set of use cases. Generally-speaking, Java applications belong on the JVM. Native compilation (again, regardless of framework choice) is going to sacrifice overall throughput in order to get the small footprint.
Thanks for raising that. That wasn’t my implication at all.
When I wrote “exploring alternatives within the Java ecosystem”, I meant exploring different runtime strategies, not excluding the JVM as a viable solution.
In this experiment, I intentionally chose Quarkus Native because I wanted to evaluate scenarios where the following factors matter:
Startup time
Memory footprint
Container density
Resource-constrained environments
Native behavior with Kafka (producer & consumer)
Native behavior with PostgreSQL and connection pooling
How native export metrics
The goal wasn’t to suggest that the JVM is not viable, far from it. The JVM remains an excellent default for many workloads.
What I wanted to understand was how a native-compiled runtime behaves under constrained environments compared to a traditional JVM deployment.
I was actually impressed by how straightforward the Quarkus native setup was and how it performed under load.
Ultimately, my intention was to encourage experimentation. Sometimes we default to the same stack out of habit and I believe it’s healthy for us as engineers to occasionally challenge those defaults and evaluate alternatives with real measurements.
Appreciate the discussion. And I will test Quarkus on the JVM soon.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello. I'm not sure comparing graalvm native in one technology to jvm of another technology is a fair comparison. You would see reduced throughput numbers if you were comparing spring native to spring jvm.
If I were trying to figure out "jvm vs native" it might be better to stick to the same technology stack & versions of things - that way you are only changing 1 variable (i.e. spring jvm vs spring native, quarkus jvm vs quarkus native).
The better comparison would be to compare jvm of one technology to another. The Quarkus team has recently open sourced all of its benchmarks and comparisons: github.com/quarkusio/benchmarks
@edeandrea As I wrote in the article:
Important Disclaimer
This is not a pure framework speed comparison.
This is intentionally not apples-to-apples.
Understood, but your statement "To optimize costs while maintaining performance, I started exploring alternatives within the Java ecosystem." implies that Quarkus on the JVM is not a viable solution?
While I'm happy you are exploring Quarkus (yay!) I just want to be clear that native compilation in general (regardless of framework) has a small set of use cases. Generally-speaking, Java applications belong on the JVM. Native compilation (again, regardless of framework choice) is going to sacrifice overall throughput in order to get the small footprint.
Thanks for raising that. That wasn’t my implication at all.
When I wrote “exploring alternatives within the Java ecosystem”, I meant exploring different runtime strategies, not excluding the JVM as a viable solution.
In this experiment, I intentionally chose Quarkus Native because I wanted to evaluate scenarios where the following factors matter:
The goal wasn’t to suggest that the JVM is not viable, far from it. The JVM remains an excellent default for many workloads.
What I wanted to understand was how a native-compiled runtime behaves under constrained environments compared to a traditional JVM deployment.
I was actually impressed by how straightforward the Quarkus native setup was and how it performed under load.
Ultimately, my intention was to encourage experimentation. Sometimes we default to the same stack out of habit and I believe it’s healthy for us as engineers to occasionally challenge those defaults and evaluate alternatives with real measurements.
Appreciate the discussion. And I will test Quarkus on the JVM soon.