{"id":501,"date":"2026-03-09T15:31:47","date_gmt":"2026-03-09T15:31:47","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/bun-vs-nodejs-in-production-2026-real-migration-st\/"},"modified":"2026-03-18T22:31:19","modified_gmt":"2026-03-18T22:31:19","slug":"bun-vs-nodejs-in-production-2026-real-migration-st","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/bun-vs-nodejs-in-production-2026-real-migration-st\/","title":{"rendered":"Bun vs Node.js en Producci\u00f3n 2026: Lo Que Aprend\u00ed Despu\u00e9s de Migrar Una API Real"},"content":{"rendered":"

Prob\u00e9 Bun 1.0 en octubre de 2023. Dur\u00e9 aproximadamente tres semanas antes de volver a Node.js con la cola entre las patas. En ese momento la compatibilidad con el ecosistema npm era, digamos, aspiracional. Muchos paquetes simplemente no funcionaban \u2014 el error m\u00e1s frecuente era un TypeError: X is not a function<\/code> en cosas que corr\u00edan perfectamente en Node. Archiv\u00e9 el experimento y segu\u00ed con mi vida.<\/p>\n

Entonces lleg\u00f3 enero de 2026 y decid\u00ed darle otra oportunidad. Bun 1.2 ten\u00eda un nivel de compatibilidad que, honestamente, no esperaba. Llevamos seis semanas en producci\u00f3n<\/a>. Esto es lo que<\/a> pas\u00f3.<\/p>\n

Por Qu\u00e9 Siquiera Vale la Pena<\/a> Revisitarlo en 2026<\/h2>\n

Somos un equipo de cuatro personas construyendo una herramienta de<\/a> an\u00e1lisis para equipos de<\/a> desarrollo \u2014 una API REST que procesa webhooks de GitHub<\/a> y GitLab, los almacena, y sirve dashboards de m\u00e9tricas. Unos 18 endpoints, PostgreSQL con pg<\/code>, Redis para cach\u00e9 con ioredis<\/code>, corriendo en AWS ECS con containers Docker sobre instancias Graviton2 (arm64). Nada ex\u00f3tico.<\/p>\n

La motivaci\u00f3n original era el tiempo de arranque de los containers. Ten\u00edamos cold starts notables en ciertos per\u00edodos de bajo tr\u00e1fico cuando ECS escalaba desde cero, y alguien del equipo mencion\u00f3 que Bun deber\u00eda ayudar ah\u00ed. Mi expectativa era validarlo r\u00e1pido, decir “s\u00ed, arranque m\u00e1s r\u00e1pido, pero no vale la<\/a> migraci\u00f3n” y cerrar el ticket.<\/p>\n

No fue as\u00ed.<\/p>\n

Lo que cambi\u00f3 mi evaluaci\u00f3n no fue el throughput de la API en producci\u00f3n<\/a> \u2014 fue algo que no estaba midiendo: el tiempo de nuestros tests. Pero eso viene despu\u00e9s.<\/p>\n

Los Benchmarks Reales: Qu\u00e9 N\u00fameros Importan y Cu\u00e1les No<\/h2>\n

Lo primero que med\u00ed fue startup. Simple: time node index.js<\/code> vs time bun index.js<\/code> en nuestra aplicaci\u00f3n real, no un hello world. Con Node.js 22.14 tard\u00e1bamos unos 820ms<\/strong> en llegar a “listening on port 3000”. Con Bun 1.2.4: 180ms<\/strong>.<\/p>\n

Eso es real. Y en nuestro caso espec\u00edfico, esa diferencia importa.<\/p>\n

Para throughput, arm\u00e9 un benchmark con wrk<\/code>:<\/p>\n

-- wrk_test.lua\n-- Simula tr\u00e1fico real: webhook POST con body JSON t\u00edpico\nwrk.method = "POST"\nwrk.body   = '{"ref":"refs\/heads\/main","repository":{"id":12345,"name":"api"}}'\nwrk.headers["Content-Type"]         = "application\/json"\nwrk.headers["X-Hub-Signature-256"]  = "sha256=abc123"\n<\/code><\/pre>\n
# 30 segundos, 50 conexiones concurrentes, 4 threads\nwrk -t4 -c50 -d30s -s wrk_test.lua http:\/\/localhost:3000\/webhooks\/github\n<\/code><\/pre>\n
En mi MacBook Pro M3 con 36GB RAM:<\/p>\n