Node.js para Bun: transição com benchmark real, compatibilidade e rollback

Migrar para Bun sem método pode trocar gargalo de performance por incidente de compatibilidade. O que funciona é abordagem incremental: escolher serviços candidatos, validar dependências nativas, medir métricas comparáveis e só então fazer cutover controlado.

Seleção de serviço candidato

Eu começo por serviços com:

1. baixa dependência de addon nativo;
2. cobertura de testes boa;
3. deploy isolado por container.

Evito iniciar por serviço monolítico crítico de faturamento/autenticação.

Pré-check de compatibilidade

1. instalar Bun atualizado:

bun --version

1. validar install:

bun install

1. executar suíte de teste:

bun test

1. validar scripts de build/start:

bun run build
bun run start

Armadilhas reais que já encontrei

Dependência com node-gyp

Sinal: falha em instalação ou crash no runtime.

Ação:

• tentar versão mais nova da dependência;
• buscar alternativa pure JS;
• manter serviço em Node se a lib for crítica e sem suporte estável.

Diferença sutil de runtime

Mesmo com JavaScript padrão, comportamento de libs pode variar entre V8 e JSC. Por isso não aceito “subiu sem erro” como critério. Exijo teste funcional de endpoint crítico e comparação de payload.

Benchmark comparável (sem autoengano)

Métrica mínima que comparo em ambiente igual:

• p95 de latência;
• throughput;
• memória residente;
• tempo de cold start;
• taxa de erro HTTP 5xx.

Ferramenta simples para carga:

autocannon -c 100 -d 30 http://127.0.0.1:3000/health

Rodar Node vs Bun no mesmo host/limite de CPU para comparação justa.

Exemplo de container com Bun

FROM oven/bun:latest
WORKDIR /app

COPY package.json bun.lockb ./
RUN bun install --frozen-lockfile

COPY . .
EXPOSE 3000
USER bun
CMD ["bun", "run", "src/server.ts"]

Estratégia de rollout que uso

1. canary de tráfego parcial;
2. monitoramento em tempo real de erro/latência;
3. rollback automático por SLO;
4. pós-análise com decisão de permanência.

Rollback objetivo

Mantenho imagem Node pronta para retorno imediato:

docker compose up -d app-node

Rollback não pode depender de recompilar durante incidente.

Critérios de aprovação para migração definitiva

Só promovo serviço para Bun quando, por janela mínima definida, mantém:

1. p95 igual ou melhor que baseline Node;
2. erro 5xx dentro do SLO;
3. consumo de memória estável sob carga contínua;
4. zero regressão funcional nos fluxos críticos.

Se qualquer item falhar, mantenho Node e abro plano de correção incremental.

Convivência híbrida (Node + Bun)

Na prática, manter runtimes coexistindo é aceitável em portfólio grande.\nServiço novo pode nascer em Bun enquanto legado sensível continua em Node,\nsem forçar migração total por moda tecnológica.

Conclusão

Bun traz ganho real em alguns cenários, mas a migração madura é orientada por métrica e compatibilidade, não hype. Quando tratada como mudança de engenharia (com benchmark e rollback), a transição fica segura e previsível.

Este post está licenciado sob CC BY-NC.