Rust vs Node.js: comparativa de backend y latencia

Sharkbench es un proyecto comunitario independiente que mide tres cosas: la capacidad de un marco para manejar solicitudes HTTP simultáneas, operaciones de E/S y serialización JSON. La prueba se ejecuta en Docker/Linux en un Ryzen 7 7800X3D, con una última actualización pública el 24 de agosto de 2025 (Sharkbench.dev/web, consultado el 24 de agosto de 2026).

Fuente: Sharkbench, 24 de agosto de 2025: Docker/Linux, Ryzen 7 7800X3D.

Axum, el marco que utiliza Aurabase para su núcleo Rust, verificado en Cargo.toml, procesa 21,030 solicitudes por segundo en este banco. Express, el framework Node.js más utilizado en producción, procesa 5.766 en el mismo hardware: un factor de 3,6. Este no es un caso aislado. Los cuatro marcos Rust probados se encuentran dentro de un rango estrecho de 18.000 a 22.000 solicitudes/s, mientras que los tres marcos Node.js probados tienen un límite entre 5.766 y 9.340.

En la práctica, "req/s" mide el rendimiento bajo una carga simultánea sostenida, no la velocidad de una solicitud aislada en un sitio de poco tráfico. Para un punto final llamado una vez cada pocos segundos, la diferencia nunca se ve. Se vuelve decisivo en un punto final activo (un flujo en tiempo real, una API pública con mucho tráfico, un trabajo que encadena miles de llamadas) donde la cantidad de solicitudes procesadas por núcleo de CPU, para el mismo hardware, establece directamente la factura de infraestructura.

La latencia promedio sigue la misma jerarquía en este banco: de 1,4 a 1,7 ms para los marcos Rust probados, en comparación con 3,4 a 5,5 ms para los marcos Node.js probados.

Fuente: Sharkbench, 24 de agosto de 2025: latencia media, no p99.

Esta cifra es un promedio, no un p99. Las pausas basura en un tiempo de ejecución administrado afectan principalmente a la cola de despacho: las solicitudes más lentas, no las medianas. Este es el tema de un artículo dedicado en esta serie: por qué la ausencia del recolector de basura cambia la latencia p99.

Rust administra la memoria por propiedad, verificada en el momento de la compilación: ningún recolector de basura se ejecuta en segundo plano e interrumpe la ejecución. El Rust Book oficial lo resume de la siguiente manera: “Ninguna de las características de propiedad ralentizará su programa mientras se ejecuta” (The Rust Programming Language, doc.rust-lang.org, consultado el 24 de agosto de 2026). La memoria se libera tan pronto como la variable que la posee sale del alcance: un momento conocido en tiempo de compilación, no una pausa impredecible en tiempo de ejecución.

fn main() {
    let data = String::from("réponse API"); // `data` posee la cadena
    process(data); // la posesión sale de aquí
    // "datos" ya no es válido aquí: no hay puntero colgante, no hay doble libre
} // Los "datos" se publican aquí, de forma determinista.

fn process(s: String) {
    println!("{s}");
} // `s` queda fuera de alcance aquí: liberación inmediata, sin pase de recolección de basura

Node.js, por el contrario, se ejecuta en un único subproceso de JavaScript y delega las operaciones de E/S al kernel a través de un bucle de eventos de varias fases (temporizadores, devoluciones de llamadas diferidas, encuestas, comprobaciones...), pero cualquier cálculo sincrónico en ese subproceso, incluido un paso de recolección de basura del motor V8, bloquea la ejecución mientras se ejecuta (documentación oficial de Node.js, nodejs.org, consultado). 24 de agosto de 2026). Ésta es una diferencia del modelo de memoria, no un detalle de implementación.

El resultado más contradictorio del mismo banco no concierne a Rust: concierne al propio Node.js. Express (un mismo código, una misma API) pasa de 5.766 solicitudes/s en Node.js a 18.917 solicitudes/s en Bun, un factor de ×3,3, sin cambiar una línea de código de la aplicación (Sharkbench, 24 de agosto de 2025).

Fuente: Sharkbench, 24 de agosto de 2025: mismo código Express, tres tiempos de ejecución de JavaScript.

En Deno, este mismo código Express tiene un límite de 6088 solicitudes/s, cerca de Node.js, lejos de Bun. El lenguaje JavaScript es idéntico en los tres casos; Es el tiempo de ejecución (su motor JS, su implementación de bucle de eventos, su recolección de basura) lo que cambia el juego. Comparar "Rust" con "Node.js" sin especificar el tiempo de ejecución, la versión y el marco es como comparar configuraciones, no idiomas.

TechEmpower Framework Benchmarks ilustra la misma idea a mayor escala. Su repositorio de código abierto se actualizó el 24 de marzo de 2026 y su ronda más reciente (ronda 23) fue objeto de una publicación fechada el 16 de marzo de 2026 (TechEmpower, consultado el 24 de agosto de 2026). Este proyecto ejecuta muchos tipos de pruebas en cientos de implementaciones, precisamente porque una sola prueba nunca representa un marco, y mucho menos un lenguaje.

Convex, actor del mercado de las bases de datos, ha formulado la posición más clara al respecto: negarse a participar en la “guerra de gráficos de barras” de marketing entre bases de datos competidoras, considerada engañosa. “Es escalar el teatro, no escalar”, escribe el equipo (Convex, consultado el 24 de agosto de 2026). Compartimos esta lectura: una simple cifra, sin una metodología publicada, no prueba nada, ni para un competidor ni para nosotros.

Lo que cambia en términos concretos: hardware (CPU, RAM), versión exacta del marco y tiempo de ejecución, tamaño de la carga útil JSON, nivel de competencia y duración de la prueba, todos varían la clasificación, a veces más que la elección del idioma en sí. Un banco que no publica estos parámetros no se reproduce, por lo tanto, no se verifica a sí mismo; consulte nuestra metodología completa y reproducible para realizar evaluaciones comparativas de un backend.

El backend principal de Aurabase está escrito en Rust, en axum y tokio, verificado en el Cargo.toml del monorepo: diez servicios (aura-gateway, aura-auth, aura-db…) comparten la misma dependencia del espacio de trabajo axum (0.8) y el mismo tiempo de ejecución tokio, en la edición 2021. La puerta de enlace que enruta el tráfico del plano de datos y del plano de administración depende de hyper además de axum; los detalles completos se encuentran en nuestro artículo sobre , la arquitectura del plano de datos/plano de administración de la puerta de enlace. La estructura del espacio de trabajo Cargo que admite estos diez servicios está documentada en nuestro artículo sobre el espacio de trabajo Cargo.

Lo que aún no tenemos es una cifra de latencia o rendimiento de Aurabase publicada con metodología y hardware documentados. Esto es deliberado: preferimos publicar la metodología antes de la figura y no al revés; este es el tema de un futuro artículo de esta serie.

Para obtener una comparación completa de la arquitectura (núcleo Rust unificado en Aurabase versus pila heterogénea Elixir/Go/TypeScript/Node documentada en un competidor directo), consulte nuestra comparación detallada Aurabase vs Supabase. Si ya está migrando un proyecto, la guía de migración de Supabase a Aurabase cubre el esquema, las políticas RLS y el SDK.

Todas las líneas citadas en este artículo, publicadas por Sharkbench el 24 de agosto de 2025 (Docker/Linux, Ryzen 7 7800X3D).

Cite estos datos: Sharkbench, “Web Framework Benchmarks”, Sharkbench.dev/web, última actualización el 24 de agosto de 2025.

En el banco citado aquí, todos los marcos de Rust se ejecutan en un rango estrecho (18.000 a 22.000 solicitudes/s, 1,4-1,7 ms) muy por delante de los marcos de Node.js en el propio Node.js (5.766-9.340 solicitudes/s, 3,4-5,5 ms). Pero el tiempo de ejecución cambia la situación tanto como el idioma: Express en Bun casi alcanza a Axum en Rust.

Si evalúa un backend únicamente en función del rendimiento bruto, solicite la metodología antes del número: hardware, versión, tamaño de carga útil, nivel de competencia. Aurabase aún no ha publicado sus propias cifras; cuando lo haga, la metodología será lo primero.