The first table made me uncomfortable: on my machine, with the lab’s realistic workload, Embedded GlassFish seemed to beat Spring Boot. If I had published then, the post would have had more punch, but it would also have been methodologically weak. I paused and added what was missing: a supported JDK for all, separate warmup, longer measured windows, fixed heap, explicit pool settings, and pg_stat_statements to attribute database cost. With that, the conclusion changed.
This post does not try to decide who "wins forever." It tells how my read changed when the benchmark became fair. And why, if I start a greenfield today with a team that already lives in Spring, I still choose Spring Boot; but if I’m in an organization with Payara/Jakarta, I try Payara Micro; and if there’s Jakarta code that wants a light executable, Embedded GlassFish enters the conversation.
Why I ran this experiment
I had an easy-to-repeat idea: "Spring Boot is always the obvious choice." I wanted to challenge it with evidence, not intuition.
I’m interested in modern Jakarta EE without nostalgia. I wanted to see if there’s real room today, not in 2012.
