The 1.5°C goal is dead: can Bun help you use less energy?

The UN just said out loud what a lot of people already suspected: the Paris Agreement's 1.5°C goal is no longer viable. The new UNEP Emissions Gap Report 2026 says we're going to pass that limit. The question now is for how long, and how much we can bring it back down afterward. And yes, this has something to do with your package.json. Relax, I'm not going to tell you that swapping Node for Bun saves the planet. But it's worth talking about what Bun changes in the energy use of what we run in production. And, more importantly, what it doesn't change.

What the UN report said

UNEP's annual report compares two things. What countries promise to cut in emissions, and what would actually need to be cut to hold back warming. The difference between the two is the "gap".

This year's conclusion is blunt. With current pledges, the world goes past 1.5°C. The technical term is overshoot. The temperature goes over the limit, and the hope is that it comes back down at some point. That would take much more aggressive cuts and carbon removal tech that doesn't even exist yet at the scale we'd need.

In dev terms: it's like blowing past your container's memory budget and hoping the garbage collector catches up before the OOM killer shows up.

Why this shows up on a dev blog

Because software has become a real slice of the world's electricity bill. The International Energy Agency estimated that data centers used about 1.5% of global electricity in 2024. Its projection is that this number more than doubles by 2030, driven mostly by AI.

Not all of that energy comes from clean sources. Every request you serve runs on a real machine, plugged into a real outlet.

On your own, you won't bend that curve. But the code you write runs millions of times. A small waste multiplied by scale stops being small.

Inefficient code doesn't disappear when you deploy. It turns into an electricity bill somewhere.

Does Bun use less energy than Node?

I need to be honest here, because this is the kind of topic that attracts hype.

Bun is faster at a lot of tasks. It starts faster, installs dependencies much faster, and usually has higher throughput on a simple HTTP server. It uses JavaScriptCore instead of V8 and was written in Zig with a lot of care around allocation. Less CPU time for the same work tends to mean less energy. So far, it makes sense.

But "tends to" is doing a lot of heavy lifting in that sentence. In practice:

• If your API spends 90% of its time waiting for PostgreSQL to respond, the runtime barely matters.
• A "hello world" benchmark is not your system. Your system has an ORM, validation, logs and three external calls.
• An idle server still burns energy. If you pay for a VM running 24/7 to serve 200 requests a day, the runtime is the least of your problems.

Where I see real, measurable gains with Bun is in anything short that runs many times. CI, scripts, tests, cold starts on serverless functions. A bun install that takes 3 seconds instead of 40, running in hundreds of pipelines a day, is CPU you actually stop burning.

How to measure instead of guessing

An opinion without numbers is just cheering. Before switching runtimes for efficiency reasons, measure. You can start simple, with tools you already have on your machine.

Time and memory for a script:

/usr/bin/time -v node scripts/generate-report.js
/usr/bin/time -v bun scripts/generate-report.js

Look at "Maximum resident set size" and "User time". Memory and CPU time are the most honest proxies for energy you'll get without a meter on the outlet.

To compare across several runs and cut out the noise:

hyperfine --warmup 3 'node dist/index.js' 'bun dist/index.js'

For an HTTP server, run the same route on both runtimes and throw load at it with oha or autocannon. Do it on a real route, with a database, not on a return "ok".

// server.ts
Bun.serve({
  port: 3000,
  async fetch(req) {
    const rows = await sql`select id, name from customers limit 50`
    return Response.json(rows)
  },
})

If the difference is 5%, the migration probably isn't worth it. If it's 40% on something that runs all day, then the conversation changes.

Where the real waste is

Switching runtimes is the most fun optimization and, almost always, the one with the smallest impact. In the projects I've worked on, runaway consumption came from somewhere else:

• Oversized machines. An 8 vCPU instance running at 4% usage because "we might need it someday".
• Queries without an index. A seq scan on a 2 million row table on every request burns more CPU in the database than any difference between Node and Bun.
• Unnecessary polling. A frontend hitting the API every 2 seconds to check if something changed, when a webhook or SSE would do the job.
• CI that always runs everything. A monorepo that builds and tests every app on every commit, even when only a README changed.
• AI on autopilot. Calling a large model for a task a regex can handle. This is the trendy kind of waste.

That last point deserves its own paragraph. Every LLM call runs on a GPU that uses way more power than your entire Express server. Using AI where it adds value is great. Using AI to format a date is burning energy out of laziness. I say this with love, because I've done it.

What I'd change in my workflow tomorrow

None of this requires rewriting your system. It's small and practical:

1. Use Bun where it shines with no risk: internal scripts, tests with bun test, installing dependencies in CI. You get an instant win and almost nothing breaks.
2. Only migrate your production server after measuring with real load. Compatibility with the Node ecosystem has improved a lot, but it's still worth testing your native libs.
3. Set up CI to run only what changed. In a monorepo this usually saves more CPU than any runtime swap.
4. Review your instance sizes once a quarter. Shut down what you don't use.
5. Run EXPLAIN ANALYZE on your five most called queries. Seriously, do it today.

Notice that only the first item mentions Bun. That's not a coincidence.

My take

The UN news is bad, and there's no git revert for it. No developer is going to solve the climate crisis by switching runtimes, and anyone selling that is selling something else. Bun is a good tool. It's fast and pleasant to use. I use it and I recommend it. But the real contribution we can make is more boring: measure, cut waste, shut down what's idle, and stop treating CPU like an infinite resource. Efficiency has always been good engineering. Now it's also a responsibility.

If you want to see how I apply this to my own systems, take a look at the projects I maintain.

The UN admitted it: the Paris Agreement's 1.5°C goal is no longer viable.

And this has more to do with our work than it seems. Data centers already use about 1.5% of the world's electricity, and that number should double by 2030.

I use Bun and I recommend it. But switching runtimes won't save the planet. If your API spends 90% of its time waiting on the database, the runtime barely matters.

The real waste is usually somewhere else. Oversized machines, queries without an index, CI that runs everything on every commit, and an LLM called to do the job of a regex.

Inefficient code doesn't disappear when you deploy. It turns into an electricity bill somewhere.

I wrote about how to measure before you change anything. The link is in the comments. I'd love to hear where you've found waste in your own systems.

#SoftwareDevelopment #Bun #Sustainability #DevOps #GreenTech