Meta de 1,5°C morreu: o Bun ajuda a gastar menos energia?

A ONU acabou de dizer em voz alta o que muita gente já desconfiava: a meta de 1,5°C do Acordo de Paris não é mais viável. O novo Emissions Gap Report 2026 do PNUMA diz que vamos passar desse limite. A discussão agora é por quanto tempo e quanto dá para trazer de volta depois. E sim, isso tem a ver com o seu package.json. Calma, não vou dizer que trocar Node por Bun salva o planeta. Mas vale a conversa sobre o que o Bun muda no consumo de energia do que a gente roda em produção, e principalmente sobre o que ele não muda.

O que o relatório da ONU disse

O relatório anual do PNUMA compara duas coisas: o que os países prometem cortar de emissões e o que precisaria ser cortado para segurar o aquecimento. A diferença entre as duas é o tal "gap".

A conclusão deste ano é direta. Com as promessas atuais, o mundo ultrapassa 1,5°C. O termo técnico é overshoot: a temperatura passa do limite e a esperança é que ela volte a cair em algum momento, à custa de cortes muito mais agressivos e de tecnologia de remoção de carbono que ainda nem existe na escala necessária.

Traduzindo para dev: é como estourar o orçamento de memória do container e torcer para o garbage collector dar conta antes do OOM killer chegar.

Por que isso aparece num blog de dev

Porque software virou uma fatia relevante da conta de luz do mundo. A Agência Internacional de Energia estimou que data centers usaram cerca de 1,5% da eletricidade global em 2024. A projeção dela é que esse número mais que dobre até 2030, puxado principalmente por IA.

Nem toda essa energia vem de fonte limpa. Cada request que você atende roda numa máquina de verdade, ligada numa tomada de verdade.

Sozinho, você não muda essa curva. Mas o código que você escreve roda milhões de vezes. Um desperdício pequeno multiplicado por escala deixa de ser pequeno.

Código ineficiente não some quando você faz deploy. Ele vira conta de luz em algum lugar.

O Bun gasta menos energia que o Node?

Aqui eu preciso ser honesto, porque esse é o tipo de assunto que atrai hype.

O Bun é mais rápido em várias tarefas. Ele sobe mais rápido, instala dependências bem mais rápido e costuma ter throughput maior em servidor HTTP simples. Ele usa JavaScriptCore em vez do V8 e foi escrito em Zig com bastante cuidado com alocação. Menos tempo de CPU para fazer o mesmo trabalho tende a significar menos energia. Até aí, faz sentido.

Só que "tende a" carrega muito peso nessa frase. Na prática:

• Se a sua API passa 90% do tempo esperando o PostgreSQL responder, o runtime quase não pesa.
• Benchmark de "hello world" não é o seu sistema. Seu sistema tem ORM, validação, logs e três chamadas externas.
• Servidor ocioso consome energia igual. Se você paga uma VM ligada 24h para atender 200 requests por dia, o runtime é o menor dos problemas.

Onde eu vejo ganho real e mensurável com Bun é em tudo que roda muitas vezes e é curto: CI, scripts, testes, cold start de função serverless. Um bun install que leva 3 segundos em vez de 40, rodando em centenas de pipelines por dia, é CPU que deixa de ser gasta de verdade.

Como medir em vez de achar

Opinião sem número é só torcida. Antes de trocar runtime por motivo de eficiência, meça. Dá para começar simples, com ferramentas que você já tem na máquina.

Tempo e memória de um script:

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

Olhe "Maximum resident set size" e "User time". Memória e tempo de CPU são os proxies mais honestos de energia que você vai ter sem um medidor na tomada.

Para comparar com várias rodadas e tirar o ruído:

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

Para servidor HTTP, suba a mesma rota nos dois runtimes e jogue carga com oha ou autocannon. Faça isso numa rota real, com banco, não num 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)
  },
})

Se a diferença for de 5%, provavelmente não vale a migração. Se for de 40% em algo que roda o dia inteiro, aí sim a conversa muda.

Onde está o desperdício de verdade

Trocar runtime é a otimização mais divertida e, quase sempre, a de menor impacto. Nos projetos que eu já peguei, o consumo fora de controle vinha de outro lugar:

• Máquina superdimensionada. Instância com 8 vCPUs rodando a 4% de uso porque "um dia pode precisar".
• Query sem índice. Um seq scan numa tabela de 2 milhões de linhas a cada request queima mais CPU no banco do que qualquer diferença entre Node e Bun.
• Polling desnecessário. Front batendo na API a cada 2 segundos para ver se algo mudou, quando um webhook ou SSE resolveria.
• CI que roda tudo sempre. Monorepo que builda e testa todos os apps em cada commit, mesmo quando só mudou um README.
• IA no automático. Chamar um modelo grande para tarefa que uma regex resolve. Esse é o desperdício da moda.

O último ponto merece um parágrafo. Cada chamada a um LLM roda numa GPU que consome muito mais que o seu servidor Express inteiro. Usar IA onde ela agrega é ótimo. Usar IA para formatar data é queimar energia por preguiça. Eu falo isso com carinho, porque já fiz.

O que eu mudaria no fluxo de trabalho amanhã

Nada disso exige reescrever o sistema. É pequeno e prático:

1. Use Bun onde ele brilha sem risco: scripts internos, testes com bun test, instalação de dependências no CI. Dá ganho imediato e quase não quebra nada.
2. Só migre o servidor de produção depois de medir com carga real. Compatibilidade com o ecossistema Node melhorou muito, mas ainda vale testar suas libs nativas.
3. Configure o CI para rodar só o que mudou. Em monorepo isso costuma economizar mais CPU que qualquer troca de runtime.
4. Revise o tamanho das suas instâncias uma vez por trimestre. Desligue o que não usa.
5. Rode EXPLAIN ANALYZE nas cinco queries mais chamadas. Sério, faz isso hoje.

Repare que só o primeiro item fala de Bun. Não é coincidência.

Minha opinião

A notícia da ONU é ruim e não tem git revert para ela. Desenvolvedor nenhum vai resolver a crise climática trocando de runtime, e quem vende isso está vendendo outra coisa. O Bun é uma ferramenta boa, rápida e agradável de usar. Eu uso e recomendo. Mas a contribuição real que a gente pode dar é mais chata: medir, cortar desperdício, desligar o que está ocioso e parar de tratar CPU como recurso infinito. Eficiência sempre foi boa engenharia. Agora ela também é responsabilidade.

Se quiser ver como eu aplico isso nos meus próprios sistemas, dá uma olhada nos projetos que eu mantenho.

A ONU admitiu: a meta de 1,5°C do Acordo de Paris não é mais viável.

E isso tem mais a ver com o nosso trabalho do que parece. Data centers já consomem cerca de 1,5% da eletricidade do mundo, e a conta deve dobrar até 2030.

Eu uso Bun e recomendo. Mas trocar de runtime não salva o planeta. Se a sua API passa 90% do tempo esperando o banco, o runtime quase não pesa.

O desperdício de verdade costuma estar em máquina superdimensionada, query sem índice, CI que roda tudo a cada commit e LLM chamado para fazer o trabalho de uma regex.

Código ineficiente não some quando você faz deploy. Ele vira conta de luz em algum lugar.

Escrevi sobre como medir antes de mudar qualquer coisa. O link está nos comentários, e quero saber onde você já encontrou desperdício no seu sistema.

#DesenvolvimentoDeSoftware #Bun #Sustentabilidade #DevOps #GreenTech