Esta elección no es un juicio absoluto sobre los dos marcos. Es un compromiso arquitectónico, documentado aquí con lo que hemos verificado en el código y en los registros públicos, no con una cifra de rendimiento no medida.
Lo esencial
Axum no construye nada propietario: depende de tower::Service para su middleware, de Hyper para el transporte y prohíbe cualquier código unsafe. Actix-web incorpora su propio sistema middleware (Logger, Session, CORS), HTTP/2 nativo y cita el TechEmpower Framework Benchmark como prueba de velocidad. En crates.io, Axum tiene hoy más de 436 millones de descargas, frente a los alrededor de 78 millones de Actix-web, a pesar de una diferencia de edad de casi cuatro años en su contra. Aurabase eligió Axum para la composición de la torre, verificada en once repositorios Cargo.toml reales, no por una cifra de rendimiento no medida.
Dos marcos, la misma base de Tokio
Axum y Actix-web se ejecutan en Tokio, el tiempo de ejecución asincrónico de referencia en Rust. El archivo README de Actix-web establece esto sin rodeos – “Compatibilidad total con Tokio” – y su ejemplo de código oficial no utiliza ningún actor del marco histórico actix: un controlador async fn clásico, anotado #[get(...)], es suficiente. La confusión “Actix-web requiere necesariamente actores” ya no corresponde a la API actual.
Axum nació en la órbita directa de Tokio: el repositorio pertenece a la organización GitHub tokio-rsy su documentación oficial es inequívoca: "axum está diseñado para funcionar con tokio e hyper. La independencia de la capa de transporte y tiempo de ejecución no es un objetivo, al menos por el momento. »
Por lo tanto, no se trata de elegir entre dos tiempos de ejecución en competencia, sino entre dos formas de crear una API HTTP sobre el mismo motor asíncrono. Esta comparación cubre cuatro áreas verificables (modelo de middleware, seguridad de la memoria declarada, superficie HTTP nativa, adopción medida en crates.io y GitHub) y luego explica, con código de respaldo, por qué el núcleo Rust de Aurabase eligió Axum.
Torre de middleware componible versus sistema integrado
Axum no construye ningún sistema de middleware propietario. Se basa completamente en tower::Service: tiempos de espera, rastreo, compresión, autorización; todo viene “gratis” a través del ecosistema Tower, según su propio archivo README. El middleware escrito para una aplicación Hyper o Tonic se puede reutilizar tal cual en una aplicación Axum, sin adaptación.
Actix-web toma el camino opuesto: incorpora su propio sistema middleware (Logger, Session, CORS, etc.), documentado en su guía de usuario, con su propio cliente HTTP asociado (awc). Es una plataforma más integrada: menos piezas para ensamblar, pero también menos reutilización directa con el resto del ecosistema asíncrono genérico de Rust.
El enrutamiento sigue la misma lógica de composición explícita. Axum afirma tener una “API sin macros” para declarar rutas (Router::new().route(...) sigue siendo un valor ordinario de Rust) donde Actix-web se basa en macros dedicadas mediante el método HTTP (#[get(...)]) colocadas directamente encima del controlador. Dos estilos de declaración, no una diferencia de habilidad.
La componibilidad de Axum tiene un costo: debe agregar tower-http para obtener CORS, compresión o limitación de tamaño de consulta, donde Actix-web los entrega internamente. Integración lista para usar versus composición explícita: una verdadera compensación, no un defecto de un lado.
Cero declarado inseguro, dos MSRV diferentes
Axum afirma #![forbid(unsafe_code)] en su código fuente: el 100% del marco está escrito en Rust seguro, sin lagunas. Actix-web no hace una declaración equivalente en su archivo README; esto no significa que el marco sea peligroso, solo que el proyecto no muestra públicamente dicha garantía.
Los dos marcos establecen una versión mínima diferente de Rust: Axum es compatible desde Rust 1.80, Actix-web requiere Rust 1.88. Una ventana más estrecha para Actix-web, lo que puede ser importante si su cadena de herramientas está atascada en una versión anterior.
Lo que cada uno envía de forma nativa
Actix-web enumera una gran superficie HTTP directamente en su caja: HTTP/1.x y HTTP/2, WebSockets, compresión transparente (br, gzip, deflate, zstd), TLS a través de OpenSSL o Rustls. Todo viene junto, sin dependencias adicionales para elegir.
Axum sigue siendo deliberadamente mínimo: enrutamiento, extractores, manejo de errores; el resto (compresión, CORS, limitación de solicitudes, seguimiento) proviene de tower-http, una caja complementaria del mismo ecosistema. Aurabase, por ejemplo, solo habilita las características cors, trace, compression-gzip, request-id, timeout y limit de tower-http: una selección deliberada, no el paquete completo.
Qué podemos comprobar y qué no republicamos
Actix-web afirma su velocidad citando una fuente externa precisa: “Uno de los marcos web más rápidos disponibles según TechEmpower Framework Benchmark” (ronda r21, compuesto), con un enlace directo a techempower.com en su propio archivo README. Este es el tipo de cotización que puede verificar usted mismo.
Axum no hace ninguna afirmación comparable. Su README se limita a una declaración más modesta: "axum es una capa relativamente delgada encima de hyper y agrega muy poca sobrecarga", con dos enlaces a puntos de referencia de la comunidad de terceros, no una cifra oficial del proyecto.
Aurabase no publica actualmente ninguna comparación cuantificada de Axum frente a Actix-web en su propia carga de producción. Un número que no hayamos medido nosotros mismos nunca se volverá a publicar aquí como argumento de producto; consulte nuestra metodología de referencia reproducible , creada precisamente para publicar un método verificable en lugar de un número simple.
Lo que dicen crates.io y GitHub al momento de escribir este artículo
En crates.io, Axum tiene 436,464,896 descargas en total, incluidas 109,000,226 durante los últimos 90 días. Actix-web acumula 78,074,020 descargas en total, incluidas 9,730,975 en la misma ventana reciente (crates.io, consultado el 23 de agosto de 2026). En este punto, la brecha es clara: Axum recibe hoy alrededor de 11 veces más descargas recientes que Actix-web.
La paradoja: Actix-web es el más antiguo de los dos, publicado en crates.io desde octubre de 2017, en comparación con julio de 2021 para Axum. En GitHub, la brecha de popularidad es más estrecha: 26,931 estrellas para tokio-rs/axum contra 24,793 para actix/actix-web (GitHub, consultado el 23 de agosto de 2026) – y Actix-web mantiene más bifurcaciones (1.880 en comparación con 1.462), una señal de una base histórica de contribuyentes aún activa.
Actix-web está lejos de estar abandonado: su versión 4.15.0 se publicó el 21 de agosto de 2026, tres días antes de escribir este artículo. En la cola de problemas de GitHub, Axum muestra 75 tickets abiertos frente a los 192 de Actix-web: una señal de mantenimiento que debe leerse con cautela: una historia de casi cuatro años más mecaniza una cola más larga, lo que no es prueba de un proyecto menos cuidadoso.
El propio README de Axum advierte que su rama main está preparando una versión 0.9 con cambios importantes: la rama estable publicada en crates.io sigue siendo 0.8.x. Si comienza hoy, fije la versión exacta en lugar de seguir la rama predeterminada del repositorio.
Por qué Axum, verificado en código
El espacio de trabajo raíz de Aurabase Cargo tiene once servicios. Diez dependen directamente de Axum, desde la puerta de enlace API (aura-gateway) hasta el motor de IA nativo (aura-ai), incluida la autenticación y el almacenamiento. El undécimo, aura-migrator, es una herramienta CLI de migración sin un servidor HTTP: simplemente no tiene nada para elegir. Ningún Cargo.toml en el repositorio, ni ninguna entrada en la raíz Cargo.lock, declara actix-web, incluso en dependencia transitiva; y ningún archivo .rs contiene la instrucción use actix_web::.
Esta elección no es cosmética: la puerta de enlace de Aurabase (aura-gateway) apila su middleware con tower::ServiceBuilder y Layer Tower ( TraceLayer, TimeoutLayer, RequestBodyLimitLayer ) complementados con capas internas a través de axum::middleware::from_fn para el identificador de solicitud, la autenticación y los encabezados de seguridad. Este es exactamente el modelo de composición que destaca el README de Axum: un middleware Tower se apila, prueba y reutiliza independientemente del resto del router.
Lo que se verifica aquí es la arquitectura elegida: la dependencia real, la composición real de los middlewares. No se afirma ninguna ganancia de rendimiento cuantificada: consulte la sección anterior sobre lo que no publicamos.
Axum y Actix-web, uno al lado del otro
| software intermedio | Torre de composición::Servicio, nada propietario | Sistema integrado (Logger, Session, CORS) |
|---|---|---|
| Seguridad de la memoria | prohibir (código_inseguro) declarado | Ninguna declaración equivalente |
| MSRV | Óxido 1.80 | Óxido 1.88 |
| Licencia | MIT | Apache-2.0 O MIT |
| HTTP nativo | Enrutamiento + extractores; el resto vía tower-http | HTTP/1.x, HTTP/2, compresión, TLS integrado |
| Descargas de crates.io (total) | 436 464 896 | 78 074 020 |
| Descargas crates.io (90 días) | 109 000 226 | 9 730 975 |
| Estrellas de GitHub | 26 931 | 24 793 |
| En crates.io desde | julio 2021 | octubre 2017 |
| Utilizado por Aurabase | Sí, 10 de 11 servicios de Rust | No, sin dependencias, directas o transitivas |
Fuentes: API de crates.io (/api/v1/crates/axum, /api/v1/crates/actix-web) y API de GitHub, consultado el 23 de agosto de 2026. LÉAME oficiales tokio-rs/axum y actix/actix-web para el resto.
¿Quién debería elegir qué?
Inicias un backend Rust modular y multiservicio. Axum encaja perfectamente: su composición en torre hace que sea más fácil compartir middleware entre servicios, como lo hace Aurabase entre sus diez servicios HTTP.
Tiene una base de código web Actix existente y en funcionamiento. No hay prisa por migrar. Actix-web se mantiene activamente y cubre HTTP/2, WebSockets y compresión de forma nativa, sin dependencias adicionales.
Desea que se entregue la mayor cantidad de funcionalidad HTTP posible en una sola caja, sin ensamblar tower-http usted mismo. Actix-web responde directamente a esta necesidad.
Ya comparte middleware Tower con otros servicios Hyper o Tonic (gRPC). Axum reutiliza estas capas tal como están: este es el argumento que pesa en Aurabase.