La meta de 1,5°C murió: ¿Bun ayuda a gastar menos energía?

La ONU acaba de decir en voz alta lo que mucha gente ya sospechaba: la meta de 1,5°C del Acuerdo de París ya no es viable. El nuevo Emissions Gap Report 2026 del PNUMA dice que vamos a pasar ese límite. La discusión ahora es por cuánto tiempo y cuánto se puede recuperar después. Y sí, esto tiene que ver con tu package.json. Tranquilo, no voy a decir que cambiar Node por Bun salva el planeta. Pero vale la pena hablar de lo que Bun cambia en el consumo de energía de lo que corremos en producción. Y, sobre todo, de lo que no cambia.

Qué dijo el informe de la ONU

El informe anual del PNUMA compara dos cosas: lo que los países prometen recortar en emisiones y lo que habría que recortar para frenar el calentamiento. La diferencia entre ambas es el famoso "gap".

La conclusión de este año es directa. Con las promesas actuales, el mundo supera 1,5°C. El término técnico es overshoot: la temperatura pasa el límite y la esperanza es que vuelva a bajar en algún momento. Eso exige recortes mucho más agresivos y tecnología de remoción de carbono que todavía no existe a la escala necesaria.

Traducido para devs: es como pasarte del límite de memoria del container y rezar para que el garbage collector lo resuelva antes de que llegue el OOM killer.

Por qué esto aparece en un blog de dev

Porque el software se volvió una parte relevante de la factura de luz del mundo. La Agencia Internacional de Energía estimó que los data centers usaron cerca del 1,5% de la electricidad global en 2024. Su proyección es que ese número se duplique con creces para 2030, impulsado sobre todo por la IA.

No toda esa energía viene de fuentes limpias. Cada request que atiendes corre en una máquina real, conectada a un enchufe real.

Solo, no cambias esa curva. Pero el código que escribes corre millones de veces. Un desperdicio pequeño multiplicado por escala deja de ser pequeño.

El código ineficiente no desaparece cuando haces deploy. Se convierte en una factura de luz en algún lugar.

¿Bun gasta menos energía que Node?

Aquí tengo que ser honesto, porque este es el tipo de tema que atrae hype.

Bun es más rápido en varias tareas. Arranca más rápido, instala dependencias mucho más rápido y suele tener mayor throughput en un servidor HTTP simple. Usa JavaScriptCore en lugar de V8 y fue escrito en Zig con mucho cuidado en la asignación de memoria. Menos tiempo de CPU para hacer el mismo trabajo tiende a significar menos energía. Hasta ahí, tiene sentido.

Pero "tiende a" carga mucho peso en esa frase. En la práctica:

• Si tu API pasa el 90% del tiempo esperando que PostgreSQL responda, el runtime casi no pesa.
• Un benchmark de "hello world" no es tu sistema. Tu sistema tiene ORM, validación, logs y tres llamadas externas.
• Un servidor ocioso consume energía igual. Si pagas una VM encendida 24h para atender 200 requests al día, el runtime es el menor de tus problemas.

Donde veo una ganancia real y medible con Bun es en todo lo que corre muchas veces y es corto: CI, scripts, tests, cold start de funciones serverless. Un bun install que tarda 3 segundos en lugar de 40, corriendo en cientos de pipelines al día, es CPU que de verdad deja de gastarse.

Cómo medir en vez de suponer

Una opinión sin números es solo hinchada. Antes de cambiar de runtime por eficiencia, mide. Puedes empezar simple, con herramientas que ya tienes en tu máquina.

Tiempo y memoria de un script:

/usr/bin/time -v node scripts/gerar-relatorio.js
/usr/bin/time -v bun scripts/gerar-relatorio.js

Mira "Maximum resident set size" y "User time". La memoria y el tiempo de CPU son los indicadores de energía más honestos que vas a tener sin un medidor en el enchufe.

Para comparar con varias rondas y quitar el ruido:

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

Para un servidor HTTP, levanta la misma ruta en los dos runtimes y lánzale carga con oha o autocannon. Hazlo en una ruta real, con base de datos, no en un return "ok".

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

Si la diferencia es del 5%, probablemente no vale la pena migrar. Si es del 40% en algo que corre todo el día, ahí sí cambia la conversación.

Dónde está el desperdicio de verdad

Cambiar de runtime es la optimización más divertida y, casi siempre, la de menor impacto. En los proyectos que me ha tocado ver, el consumo descontrolado venía de otro lado:

• Máquina sobredimensionada. Una instancia con 8 vCPUs corriendo al 4% de uso porque "algún día puede hacer falta".
• Query sin índice. Un seq scan en una tabla de 2 millones de filas en cada request quema más CPU en la base de datos que cualquier diferencia entre Node y Bun.
• Polling innecesario. El front consultando la API cada 2 segundos para ver si algo cambió, cuando un webhook o SSE lo resolvería.
• CI que corre todo siempre. Un monorepo que hace build y test de todas las apps en cada commit, aunque solo haya cambiado un README.
• IA en piloto automático. Llamar a un modelo grande para una tarea que resuelve una regex. Este es el desperdicio de moda.

El último punto merece un párrafo. Cada llamada a un LLM corre en una GPU que consume mucho más que todo tu servidor Express. Usar IA donde aporta es genial. Usar IA para formatear una fecha es quemar energía por pereza. Lo digo con cariño, porque yo también lo hice.

Qué cambiaría mañana en el flujo de trabajo

Nada de esto exige reescribir el sistema. Es pequeño y práctico:

1. Usa Bun donde brilla sin riesgo: scripts internos, tests con bun test, instalación de dependencias en el CI. La ganancia es inmediata y casi no rompe nada.
2. Migra el servidor de producción solo después de medir con carga real. La compatibilidad con el ecosistema Node mejoró mucho, pero aún vale la pena probar tus libs nativas.
3. Configura el CI para correr solo lo que cambió. En un monorepo esto suele ahorrar más CPU que cualquier cambio de runtime.
4. Revisa el tamaño de tus instancias una vez por trimestre. Apaga lo que no usas.
5. Corre EXPLAIN ANALYZE en las cinco queries más llamadas. En serio, hazlo hoy.

Fíjate que solo el primer punto habla de Bun. No es casualidad.

Mi opinión

La noticia de la ONU es mala y no tiene git revert. Ningún desarrollador va a resolver la crisis climática cambiando de runtime, y quien vende eso está vendiendo otra cosa. Bun es una herramienta buena, rápida y agradable de usar. La uso y la recomiendo. Pero la contribución real que podemos hacer es más aburrida: medir, cortar desperdicio, apagar lo que está ocioso y dejar de tratar la CPU como un recurso infinito. La eficiencia siempre fue buena ingeniería. Ahora también es responsabilidad.

Si quieres ver cómo aplico esto en mis propios sistemas, échale un vistazo a los proyectos que mantengo.

La ONU lo admitió: la meta de 1,5°C del Acuerdo de París ya no es viable.

Y esto tiene más que ver con nuestro trabajo de lo que parece. Los data centers ya consumen cerca del 1,5% de la electricidad del mundo, y la cifra debería duplicarse para 2030.

Yo uso Bun y lo recomiendo. Pero cambiar de runtime no salva el planeta. Si tu API pasa el 90% del tiempo esperando a la base de datos, el runtime casi no pesa.

El desperdicio de verdad suele estar en máquinas sobredimensionadas, queries sin índice, un CI que corre todo en cada commit y un LLM llamado para hacer el trabajo de una regex.

El código ineficiente no desaparece cuando haces deploy. Se convierte en una factura de luz en algún lugar.

Escribí sobre cómo medir antes de cambiar cualquier cosa. El link está en los comentarios, y quiero saber dónde ya encontraste desperdicio en tu sistema.

#DesarrolloDeSoftware #Bun #Sostenibilidad #DevOps #GreenTech