Why Quarkus Finally “Clicks”: The 10 Questions Java Developers Ask Most
A field guide based on real conversations at conferences, meetups, and across The Main Thread community.
Over the past year I’ve had the same conversation again and again.
At conferences. In workshops. In DMs from readers. In comment threads on The Main Thread. Even in quick chats after my talks, when someone stops me with that look of “Okay, so… I think I get it, but maybe I don’t?”
It’s almost always the developer who has been using Quarkus for a while. Not a beginner. Someone who has built a few services, maybe put one into production, maybe containerized something, maybe tried a native build. They’ve seen Quarkus work, but they haven’t had the “ohhhhhh” moment yet.
And every time, they ask one of the same ten questions.
These aren’t rookie questions. These are the questions you only start asking around month six. When the basic stuff is behind you and the deeper parts start to matter. When you stop comparing Quarkus to Spring and start looking at Quarkus on its own terms. When speed is no longer the headline and the architecture becomes the real story.
So I turned those hallway conversations and community threads into something I wish more developers had early on. A map of the questions you eventually ask as Quarkus starts to click.
Let’s go through them. And if you’ve been in any of these conversations with me at an event… thank you. You helped shape this.
1) “Why does Quarkus actually start so fast? What’s really happening at build time?”
This is the most common question I hear after a talk. A developer walks up, smiling, slightly embarrassed, and says something like:
“Okay… I know it’s fast. But why? What’s it doing differently?”
That’s the moment Quarkus becomes more than a framework.
The short version? Quarkus does the heavy work ahead of time. Scanning. Indexing. Dependency graphs. Annotation processing. Bytecode generation. All at build time. So by the time your application boots, the runtime doesn’t need to think. It just runs.
If you want to explore this deeply, I wrote What’s Really Going On In Your Quarkus Application, where I break down build-time vs runtime and why that matters:
Once someone understands this, Quarkus stops feeling “fast by accident” and starts feeling like “fast by design.”
2) “When should I go reactive instead of imperative?”
This usually comes from someone who has just discovered Mutiny, or was confused by a method returning Uni<T> when they expected T.
And inevitably they ask:
“So when do I actually need reactive?”
Reactive isn’t an ideology in Quarkus. It’s a tool.
Use it when concurrency is high, IO dominates CPU, or your workloads involve massive numbers of simultaneous connections. Otherwise, imperative is perfectly fine — and often simpler.
If you want a gentle entry point, my article Reactive Java Simplified might help:
And if you want a hands-on lab-style walk-through:
What I tell developers is this: Quarkus gives you both styles because real-world systems need both.
3) “What’s the real difference between Dev Services and Testcontainers?”
This one comes from developers during workshops almost every time. They’ve used Testcontainers in Spring Boot and assume it works the same way everywhere.
Then they see Quarkus Dev Services spin up Postgres, Kafka, Redis, Keycloak, all automatically, and suddenly they’re suspicious:
“Hold on… why didn’t I configure anything? Is it still real Testcontainers?”
Yes. But Quarkus manages the lifecycle for you.
It wires the ports, injects config, handles networks, and cleans up after itself. Dev Services feels like Testcontainers without the ceremony.
If you want to see Dev Services explained, I have a full guide:
And if you want to embrace the productivity side, continuous testing amplifies it dramatically:
This is usually the moment a developer says:
“Oh. Wow. That’s… actually nicer than what I’m used to.”
4) “How is Quarkus DI different from Spring DI? Is @Inject the same as @Autowired?”
This question comes mostly from Spring developers, of course.
It always begins with:
“So CDI… is that like Spring without @Autowired?”
Sort of, but also not really. CDI is a standard. Spring is a framework.
CDI embraces type-safety, scopes, and build-time discovery in a much clearer way. And once developers see qualifiers and alternatives, everything starts making sense.
Here are two pieces that help people transition:
Basics:
Advanced CDI (native images, scopes, reactive):
In every conference Q&A, this is the moment Spring developers start nodding slowly and thinking, “Okay… this is actually coherent.”
5) “What’s the right way to manage configuration across environments?”
Around month six, developers finally hit the pain:
local, dev, stage, prod, containers, secrets, overrides.
Every team eventually asks:
“Should we use profiles? Multiple files? External config? All of it?”
Quarkus config scales down for local development and scales up for Kubernetes without forcing you to choose one pattern.
https://www.the-main-thread.com/p/quarkus-configuration-guide-kubernetes-secrets-configmaps
This is usually the point when people realize that Config + Kubernetes + Quarkus is a cohesive story rather than four separate topics.
6) “How do I test Quarkus applications correctly? I heard @QuarkusTest works differently.”
Yes. It does. And understanding that unlocks a lot.
Quarkus boots once for the entire test suite. This changes the entire mental model compared to Spring Boot. People often discover this accidentally and then ask:
“Okay… so when do I use QuarkusTest vs QuarkusIntegrationTest? And how do I mock things?”
I wrote a detailed testing guide that has become one of the most-referenced articles on the site:
Every time I show continuous testing live, someone in the room whispers “Oh that’s dangerously good.”
7) “What is Panache actually doing behind the scenes?”
The moment developers get past “Panache is nice syntax” they start asking real questions:
“Is it wrapping EntityManager?
Is it generating queries?
Where does the magic stop?”
Panache is opinionated JPA. Clean defaults. Active Record style. But still grounded in Hibernate.
To go deeper, these articles help:
Entity design patterns with Panache:
Composite Keys (a common pain point):
Soft Deletes with Hibernate Filters:
And for DB initialization:
Panache is one of those features that feels magical until you learn how it works — and then it becomes predictable, which is even better.
8) “Should we use native images? And if so, when?”
This question almost always appears after someone tries their first native build and goes:
“Why is this build slow… but the app so fast!?”
Native images shine when startup time and memory footprint matter: FaaS, serverless, autoscaling, edge deployments. But not every app benefits.
You cover all this in your benchmarking guide:
And if developers want to understand how to package Quarkus for real production containers:
This topic always leads to strategy conversations rather than technical ones — which is a good sign.
9) “How does Quarkus actually integrate with Kubernetes and OpenShift?”
Once someone deploys Quarkus to Kubernetes for the first time, they notice something interesting:
it behaves like it belongs there.
Health checks. Metrics. Probes. Config. Startup time.
Developers who have been fighting YAML for years suddenly ask:
“Wait… Quarkus can generate Kubernetes resources for me? Why isn’t this talked about more?”
Two articles worth pointing them to:
OpenShift + PostgreSQL guide:
Kubernetes Operator pattern with Quarkus:
It’s usually after these discussions that someone says, “Okay, I get it. It’s not just fast. It’s designed for this world.”
10) “How do I integrate AI into my Quarkus application?”
This might be the biggest shift I’ve seen in the past year — the moment AI stops being a playground project and becomes a backend feature request.
Developers now ask:
“We want embeddings.”
“We want retrieval.”
“We want guards, observability, tool-calling.”
“Can Quarkus do this without Python?”
The answer is: yes. Better than people expect.
Here’s the progression I usually recommend:
Start simple with LangChain4j + Quarkus:
Then try local models with Ollama:
Add guardrails:
Understand observability:
And when ready, step into multi-agent systems:
These are some of the conversations that have surprised me the most — not because developers are confused, but because of how ambitious they’ve become.
The Moment It Clicks
Across all conversations — at conferences, in workshops, in community threads, and in casual chats — there is one universal pattern.
The moment Quarkus clicks is never when someone learns Quarkus.
It’s when they stop treating it like “a faster Spring Boot” or “a modern framework” and start seeing the design underneath:
build-time execution, developer service ergonomics, efficient DI, predictable configuration, and a deep alignment with cloud-native and AI-native workloads.
Once those ideas land, developers don’t ask “why Quarkus?” anymore.
They ask “why did we wait this long to try it?”