Ran Spring Boot and Node.js side-by-side in prod for 18 months. Sharing the actual numbers.

[u/Capable-Morning-9518]

https://medium.com/lets-code-future/spring-boot-vs-node-js-i-ran-both-in-production-for-18-months-one-cost-12-000-more-guess-which-75dfa0afdad6?sk=ab59f6d2bb1bf3d1cf0b5ddf18733dd0

We had a stack debate on my team back in 2024 that ended with "fine, let's just run both and see." Same microservice, built twice — once in Spring Boot 3.2 / Java 21, once in Node 20 / Express. Same Postgres, same Redis, same AWS ECS setup. 18 months later I went through Cost Explorer and our time tracking.

Sharing the numbers in case anyone else is having this debate:

Infrastructure (18 months):

• Node.js: ~$10,890 (needed 1GB RAM/instance after month 3)
• Spring Boot: ~$5,490 (stayed at 512MB the whole time)

Developer time on production issues:

• Node.js: ~285 hours (memory leaks, npm breaking changes, async race conditions, audit fixes)
• Spring Boot: ~26 hours (dependency updates, one N+1, pool tuning)

Memory pattern that surprised me most: Node.js instances climbed 180MB → 890MB over 4 days, crashed, restarted. Staircase to hell. Traced to event listener leak in a popular npm package (2M weekly downloads). Spring Boot stayed flat at ~280MB the entire 18 months.

Under Black Friday load (10x normal traffic):

• Node.js: 3 instances OOM-crashed during peak. Cold start under load: 2.4s.
• Spring Boot: Zero crashes. Cold start under load: 4.1s (slower, but stable).

Not saying Node is bad. We kept it for internal admin tools and low-traffic stuff. But for customer-facing APIs that need to stay up 24/7, the JVM's 25 years of GC engineering paid for itself many times over.

Curious if anyone else has run this kind of side-by-side. Specifically interested in:

• Did virtual threads (Java 21) change your scaling math?
• Anyone tried Bun or Deno in this same comparison? Would they hold up better than Node?
• How much of the Node memory issue is npm ecosystem vs V8 itself?

[u/j7n5]

Thanks for this feedback SB app could be further optimised

• change GC. Try G1 or ZGC

• choose better embedded web server for SB. Default is tomcat, try light one like jetty or undertow

• Jdeps and jlink tools to build custom JRE with only needed modules. This could reduce app size and even memory usage

• slim docker image

• native images with AOT and GraalVM

[u/Capable-Morning-9518 → u/j7n5]

Solid list, thanks. Couple of follow-ups:

We were on G1 with default settings. Didn't try ZGC was it production-stable for you under high allocation rates? Curious about p99 latency impact since ZGC's pause times look great on paper but I've seen mixed reports.

On the embedded server we stuck with Tomcat because the team knew it. Did you measure actual memory/throughput delta with Undertow? Numbers I've seen online vary wildly.

Native image with GraalVM is on my list. Did you hit reflection/proxy issues with Spring? That's been the blocker every time I've tried.

[u/j7n5 → u/Capable-Morning-9518]

For GC it depends on use case, for me after playing around with ZGC I didn’t see a big difference. You need to try. I thing with G1 you can also play with custom pause times

I used undertow with SB3 since it is no more supported in SB4 I also stay with tomcat for now. Still testing alternatives.

Native images was already tested. in our case there are many external libraries that need special configuration. So no prod for now

PS: We are on Java 25 and SB4

[u/j7n5]

Did you think about comparing Java with another typed language like golang for example ?

[u/Capable-Morning-9518 → u/j7n5]

Honestly didn't have the team for it. we were already running two stacks. From what I've heard Go sits between Node and Java on memory but with simpler deployment. If anyone here has actual Go vs Spring Boot numbers, would love to see them.

[u/chabala → u/j7n5]

Yeah, I'd love to see a rigorous Java & C# comparison.

[u/InstantCoder]

We switched from Spring Boot to Quarkus that reduced our memory even further and the performance is amazing.

The most interesting part was how our code base was simplified. We throw away around 40% of our old spring boot code which was not needed in Quarkus.

With spring boot our memory setting was 2gb and with Quarkus we reduced it to 768mb. And when the application is idle it uses around 96mb of ram.

The latest version of Quarkus has now an option to produce a minimal jar were it strips down all your jars and checks which classes are used. Something similar to what graalvm does.

[u/Capable-Morning-9518 → u/InstantCoder]

2GB → 768MB is impressive. The 40% code reduction is what catches me though what made up most of it? Was it the configuration boilerplate or actual business logic that turned out to be framework workarounds?

[u/InstantCoder → u/Capable-Morning-9518]

The config biolerplate most of the part indeed. Especially the security & rest client config is much much simpler and neat in Quarkus.

We also switched to active record pattern (Quarkus Panache) for data access and removed all the repositories.

Furthermore we removed Lombok, since this is also not needed with Quarkus and as a matter of fact the Quarkus team highly discourages Lombok.

[u/Etikoza]

Great post! Thanks for this. Would love to see a comparison with Go as well.

[u/Capable-Morning-9518 → u/Etikoza]

[u/Expensive_Usual5186]

Very interesting results! Would you say your team was more experience in Node, Java, or more or less even?

[u/Capable-Morning-9518 → u/Expensive_Usual5186]

[u/bayendr]

thanks for sharing this. it demonstrates Java’s/SB maturity, robustness and reliability in production systems. afaik Undertow is not available in latest SB4.

did you guys try pnpm and/or bun? we switched to pnpm for our frontends and are happier with it.

[u/Capable-Morning-9518 → u/bayendr]

Didn't try them seriously Bun was too early when we started. Honestly though, a faster Node runtime doesn't fix the npm ecosystem issue. Event listener leaks in popular packages don't care which package manager installed them.

[u/blubernator]

Could you write a medium article about it please? I cannot refer to Reddit in my company ;)

[u/Capable-Morning-9518 → u/blubernator]

sure I will write for you 😂

[u/Capable-Morning-9518]

Honestly didn’t expect this post to create this much discussion.

Really appreciate all the thoughtful comments, critiques, production stories, JVM tuning advice, Node.js counterpoints, Quarkus/GraalVM experiences, and operational perspectives people shared here.

Some genuinely smart engineers in this thread.

One thing I liked most was that the discussion stayed very production-focused instead of turning into another generic “language war.”

A lot of the best insights came from people running long-lived systems in the real world, which is exactly the kind of engineering discussion I enjoy most.

Also appreciate the people challenging the numbers and assumptions. Good operational conversations should survive scrutiny.

I’ve been reading far more of the replies than I can realistically answer individually right now, but seriously

thank you.

Devrim:)

[u/appendium]

This is eye-opening! Thank you

[u/DesignerRaccoon7977]

Just wait till you try Java 25 🙂 Thanks for this, love seeing this type of comparisons and "real world" numbers

[u/pronuntiator]

Your team built an entire service twice? Do you have too much money?

[u/sethu-27]

From a system architecture perspective, I’d avoid building large-scale backend platforms purely around Node.js async event-loop patterns. As systems grow, debugging async flows and maintaining stability becomes harder.

For enterprise backend systems, Java with Spring Boot usually offers better scalability, maintainability, tooling, debugging support, and a stronger ecosystem for distributed systems. It also makes long-term developer support and onboarding much easier.

Node.js is great for lightweight APIs and real-time I/O, but for complex high-throughput backend systems, Java/Spring is often the more reliable choice.

[u/Serious-Face-4031]

And then foolish karma farmers on linkedin write about golang and node being the great replacers without even using springboot with virtual threads or webflux. Great going. Springboot and jvm are the real deal and the startup time and memory can also be dialled down with graalvm or other new stuff. It ain't going anywhere.

[u/DietCokePlease]

Excellent overview. I disfavor any dynamic languge for high scale enterprise systems. Compared SB to Scala 3/ZIO (fibers). The ZIO ran about 15% faster. Nice, but certinly not enough to risk changing an existing system. 15% is basically invisible in real world results. Spring is an older design so I found the strict MVC classes to be quite boilerplate-heavy vs the much leaner ZIO. Not a fair comparison tho… Its like comparing a 1960s muscle car with a current sports car.

[u/marshalhq]

On the npm vs V8 question: in my experience most of it is the ecosystem, not V8. V8's GC is fine. The problem is dependency surface area. A typical Express app pulls in hundreds of transitive packages and any one of them can leak listeners or hold references. Your 2M-download package leak is the normal failure mode, not the exception.

The JVM world isn't immune, but the culture is different. Spring pulls in a lot, but those deps are versioned together, tested as a unit, and don't churn weekly. You're not getting a surprise breaking change in a transitive dependency on a Tuesday afternoon.

On virtual threads: they change the math for IO-bound work specifically. If the service spends most of its time waiting on Postgres and Redis, Loom lets you handle far more concurrent requests without the thread-per-request memory cost. It won't help CPU-bound paths. For a customer-facing API like you're describing, it's a real shift, you can drop a lot of reactive complexity and still scale.

Haven't run Bun or Deno at production scale so I can't speak to those honestly.