Três semanas antes de lançar um dashboard fintech para um cliente de pagamentos no ano passado, minha senior dev Priya entrou no nosso escritório em Shoreditch e disse "quero migrar a camada de API para Bun." Quase recusei por instinto. Depois não recusei. Essa decisão me ensinou mais sobre ambos os runtimes do que qualquer thread de benchmark no Hacker News jamais poderia.
Eu construo com Node desde 2015. Na Seahawk Media enviamos mais de 12.000 sites e aplicações em WordPress, Next.js, Remix, Express puro, e coisas bem mais estranhas. Bun entrou no nosso stack de verdade por volta de meados de 2023. Agora tenho uma opinião de fato. Não um hot take. Uma opinião.
Aqui está o que eu realmente aprendi.
---
A Conversa de Benchmark É Principalmente Ruído
A cada seis meses alguém posta uma comparação nova mostrando Bun tratando 80.000 requisições por segundo contra 40.000 do Node em algum teste HTTP hello-world sintético. E honestamente? Esse número é real. Os próprios benchmarks do Bun mostram throughput genuinamente impressionante, especialmente em workloads I/O-bound.
Mas aqui está a coisa. Ninguém roda hello-world em produção.
No momento que você adiciona um ORM real, um cliente Redis, três camadas de middleware, validação JWT e um handler de upload de arquivo, o gap diminui consideravelmente. Rodei apps idênticos compatíveis com Express (um em Node 22, outro em Bun 1.1) contra uma instância Postgres para o projeto fintech e vi Bun vencer por cerca de 18% em latência p50. Significativo, não milagroso.
Onde a velocidade realmente importa
O lugar onde notei mais a vantagem de performance do Bun não é throughput HTTP. É tempo de startup e execução de scripts. Rodar um script de migração de dados único que Node leva 1.4 segundos para iniciar? Bun faz em 180ms. Para CLI tooling, scripts dev locais e jobs agendados, essa diferença se acumula em melhoria real de qualidade de vida em toda a equipe.
---
O Ecossistema Node Ainda É Uma Vantagem Injusta
Quero ser direto sobre isso porque vejo muitas pessoas passarem por alto. O ecossistema npm do Node tem 15 anos. Bun é compatível com a maioria dele, sim, mas "maioria" está fazendo bastante trabalho nessa sentença.
No início de 2024, um projeto de cliente precisava de sharp para processamento de imagem server-side. Simples o suficiente. Exceto a versão específica que precisávamos tinha uma native binding que a camada FFI do Bun não tratava limpa na época. Queimamos um dia nisso antes de simplesmente migrar esse serviço de volta para Node 20. Sem drama, sem ideologia, só pragmatismo.
A história de compatibilidade melhorou muito desde então. Mas se seu stack depende muito de addons Node nativos (pense em canvas, argon2, qualquer coisa com bindings .node), teste bem antes de se comprometer. Não assuma. Verifique o rastreador de compatibilidade do Bun antes de começar uma migração.
Gerenciamento de pacotes é uma história diferente
O gerenciador de pacotes do Bun é genuinamente mais rápido que npm, e agora eu o uso até em projetos Node. bun install em um projeto com 400 dependências leva cerca de 8 segundos no meu MacBook Pro M2. npm leva 47 segundos na mesma máquina. Isso não é um benchmark. Sou eu cronometrando na terça passada com time bun install versus time npm install.
Uso Bun como gerenciador de pacotes com Node como runtime em provavelmente 60% dos nossos projetos agora. O melhor dos dois mundos.
---
TypeScript: Bun Vence Essa com Clareza
Vou ser direto. Rodar TypeScript no Node ainda requer um passo de build, ou ts-node, ou tsx, ou alguma combinação de configuração que me faz querer deitar na cama. Bun roda arquivos .ts nativamente sem config. Nenhuma.
Para ferramentas internas na Seahawk, isso foi transformador. Escrevo um script TypeScript, rodo com bun script.ts, pronto. Sem tsconfig.json acrobáticos, sem drama de esm vs cjs. Para um time que entrega rápido em vários projetos de cliente, a redução de atrito é real.
A ressalva: Bun usa seu próprio transpiler TypeScript, não o compilador oficial. Então erros de tipo não param a execução. Ele remove os tipos e roda. Se você está contando com o compilador TypeScript para garantias de correção em runtime (você não deveria estar, mas as pessoas fazem), isso é uma lacuna a entender.
---
O Que Eu Realmente Rodo em Produção Agora
Deixe-me ser específico porque generalizações vagas não ajudam ninguém.
Em Node 22:
- Todos os backends WordPress headless usando WPGraphQL + Apollo Server
- Qualquer serviço com dependências binárias nativas
- APIs Express de longa duração com stacks de middleware battle-tested
- Qualquer coisa tocando codebase legado com módulos CommonJS pesados
Em Bun 1.1+:
- Ferramentas CLI internas e scripts de dev
- Novos serviços de API baseados em Hono (Hono em Bun é genuinamente lindo)
- Jobs cron agendados e scripts de migração pontuais
- Receptores de webhook e serviços leves adjacentes a edge
O padrão é bem simples. Greenfield e ferramentas internas: Bun. Serviços de produção voltados para cliente com árvores de dependência complexas: Node, a menos que haja uma razão específica para mudar.
---
O Incidente do SQLite (E o Que Me Ensinou)
Mencionei isso no topo. Vale explicar.
Bun vem com um driver SQLite integrado. Rápido, sem dependências, genuinamente útil. Em um ambiente de staging para uma ferramenta de gerenciamento de conteúdo no final de 2023, usamos para armazenar dados de sessão. Depois de uma série particularmente agressiva de escritas concorrentes durante teste de carga, o arquivo de banco ficou em um estado estranho. Não corrompido além da recuperação, mas travado de um jeito que exigiu intervenção manual às 2 da manhã meu horário.
Foi um bug do Bun especificamente? Honestamente, não tenho certeza. Pode ter sido nossos padrões de escrita. Mas na mesma carga de trabalho, a configuração Node + better-sqlite3 que testei depois não reproduziu.
A lição não é "SQLite do Bun está quebrado." É que as APIs integradas do Bun, por mais convenientes que sejam, têm menos área de superfície da comunidade. Quando algo dá errado às 2 da manhã, você quer threads do Stack Overflow e issues do GitHub. Node tem dezessete anos disso. Bun tem três.
---
Compatibilidade de Deploy e Ferramentas
Esta seção importa mais do que as pessoas admitem.
Vercel, Railway, Render e Fly.io já suportam deployments com Bun. Railway em particular tornou isso bem simples, mais ou menos tão fácil quanto Node. AWS Lambda é mais complicado. Você está empacotando um runtime customizado ou usando uma layer, o que adiciona complexidade.
Docker funciona bem. oven/bun é a imagem base oficial e funciona muito bem. Uso em vários serviços. A imagem é mais enxuta que os equivalentes Node se você se importa com isso.
O que é menos maduro é a camada de observabilidade. Ferramentas como o agente Node.js APM do Datadog, certos pacotes de auto-instrumentação OpenTelemetry e alguns recursos do SDK do Sentry funcionam de forma diferente ou não funcionam em Bun. Perdi cerca de quatro horas na primavera passada tentando descobrir por que distributed traces estavam perdendo spans em um serviço Bun. Acabou sendo uma diferença na propagação de contexto assíncrono. O comportamento do AsyncLocalStorage do Node e a implementação do Bun divergem de formas sutis que te mordem no tracing.
Se você está rodando observabilidade de produção séria, teste sua stack inteira de telemetria antes de ir live em Bun. Não depois.
---
Minha Visão Honesta sobre a Pergunta "Devo Trocar?"
Aqui está um framework rápido que uso quando um cliente ou membro da equipe pergunta:
- É um projeto novo sem dependências legadas? Avalie Bun seriamente.
- Você está escrevendo principalmente ferramentas internas ou scripts? Use Bun. Hoje.
- Você precisa de addons nativos ou pacotes npm muito específicos? Fique com Node, teste primeiro.
- Tempo de startup ou velocidade de execução de scripts é um ponto de dor? Bun vai ajudar notavelmente.
- Você está em AWS Lambda ou em uma plataforma sem suporte de primeira classe a Bun? Node é menos fricção.
- Sua equipe já está familiarizada com as peculiaridades do ecossistema Node? Considere a curva de aprendizado nas diferenças do Bun.
E algumas coisas que valem a pena acompanhar:
- O suporte Windows do Bun melhorou dramaticamente mas ainda está atrás de macOS e Linux em casos extremos
- O test runner built-in
bun:testé realmente bom, mas plugins Jest que você depende podem não funcionar - Hot module reloading com
--hoté impressionante mas ocasionalmente imprevisível em grafos de módulos complexos
---
FAQ
Bun é production-ready em 2026?
Para casos de uso específicos, absolutamente sim. Para um serviço API greenfield com dependências nativas mínimas, Bun é production-ready e tem sido por um tempo. Para aplicações enterprise complexas com anos de dependências específicas do Node, eu chamaria de "production-ready com ressalvas". As ressalvas não são dealbreakers mas exigem diligência.
Devo migrar projetos Node existentes para Bun?
Quase certamente não, a menos que você tenha um problema específico que Bun resolve para esse projeto. Migrações carregam risco. Se seu app Node está funcionando, o custo de produtividade de migrar raramente compensa comparado a apenas usar Bun em novos projetos. Nunca migrei um único projeto cliente existente. Comecei novos em Bun.
Bun é mais rápido que Node para todas as cargas de trabalho?
Não. Cargas de trabalho CPU-bound mostram diferença mínima porque ambos acabam rodando V8 (Node) ou JavaScriptCore (Bun). Os ganhos aparecem mais em cargas de trabalho I/O-intensivas, tempo de startup e qualquer coisa onde implementações nativas do Bun (servidor HTTP, I/O de arquivo, SQLite) substituem equivalentes da camada JavaScript. Para um serviço intensivo em computação, você não vai notar muito.
Qual framework funciona melhor com Bun?
Hono é o que eu pego. É leve, TypeScript-first e foi desenhado com runtimes como Bun em mente. ElysiaJS é a outra escolha popular e é nativo de Bun, com números de benchmark impressionantes. Usei ambos. Hono eu confio mais em produção porque a comunidade é maior e os casos extremos estão melhor documentados.
Bun eventualmente vai substituir Node?
Provavelmente não substituir. Coexistir. Node tem muito momentum institucional em ambientes enterprise e o ecossistema npm vai manter ambos relevantes por muito tempo. O que Bun já fez foi empurrar Node a melhorar. Node 22 é significativamente mais rápido que Node 18, em parte porque a competição existe. Isso é bom para todos escrevendo JavaScript server-side.
---
O runtime que você escolhe importa menos que o código que você escreve em cima dele. Mas escolher o errado para o projeto errado custa seu tempo, e tempo é a única coisa que não posso comprar mais. Use Bun onde faz sentido. Confie em Node onde ele merece. E pelo amor de tudo, use bun install nos dois.