Tako vs Axum vs Actix Web
How Tako compares with Axum and Actix Web on transports, runtimes, bundled middleware, ecosystem, and throughput, and when to pick each one.
Axum and Actix Web are the two most widely used Rust web frameworks. Tako shares their handler model: async functions, typed extractors, and responses built from a trait. The three differ mainly in how much ships in the box and how many transports one application can serve. The Tako maintainers wrote this page; it aims to be fair to all three, and the throughput numbers link to a reproducible methodology.
Summary
- Axum keeps a small core and builds on the Tower ecosystem. Pick it when you want Tower middleware, the largest community, and mostly HTTP/1.1 and HTTP/2 APIs.
- Actix Web has been around since 2017 and has the fastest default setup in hello-world benchmarks; Tako's opt-in per-thread server is 3% ahead of it on loopback and 7% ahead when the server is the bottleneck. Pick Actix Web when a long track record and fast defaults matter most.
- Tako puts several transports behind one router and middleware stack, and bundles auth, sessions, rate limiting, and metrics. Pick it when one service speaks HTTP/3, WebSocket, SSE, gRPC, or raw TCP/UDP alongside plain HTTP, or when you want Compio or a thread-per-core server inside the same framework.
Feature comparison
Versions compared: Tako 2.4, Axum 0.8, and Actix Web 4.
| Tako | Axum | Actix Web | |
|---|---|---|---|
| HTTP/1.1 | Yes | Yes | Yes |
| HTTP/2 | Yes (http2, including h2c) | Yes (http2 feature) | Yes |
| HTTP/3 (QUIC) | Yes (http3) | No built-in support | No built-in support |
| WebTransport | W3C sessions over HTTP/3 (webtransport) | No built-in support | No built-in support |
| TLS | Built in: rustls, mTLS, SNI, hot reload | Via axum-server or a rustls acceptor | Built in: rustls or OpenSSL |
| WebSocket | Built in (ws) | Built in (ws feature) | actix-ws crate |
| Server-Sent Events | Built in (sse) | Built in | actix-web-lab crate |
| gRPC | Unary, server, client, and bidirectional streaming (grpc) | Through tonic, which shares hyper and Tower | No first-party support |
| Unix sockets | Yes | Yes, axum::serve accepts a UnixListener | Yes (bind_uds) |
| Raw TCP and UDP servers | Built in | Not in scope; use Tokio directly | Not part of the web framework |
| Runtime | Tokio, or Compio (io_uring on Linux, IOCP on Windows) | Tokio | actix-rt, a Tokio runtime per worker thread |
| Thread-per-core server | per-thread feature | Not built in | Worker-per-core by design |
| Middleware model | Tako middleware and plugins; no Tower compatibility | Tower layers and middleware::from_fn | Actix Transform and middleware::from_fn |
| Auth, sessions, CSRF, rate limiting, idempotency | Bundled, feature-gated | Separate crates such as tower-http, tower-sessions, tower_governor | Separate crates such as actix-session, actix-identity, actix-governor |
| OpenAPI | utoipa and vespera integrations | Community crates (utoipa-axum, aide) | Community crates (utoipa-actix-web, apistos) |
| GraphQL | async-graphql integration | async-graphql-axum | async-graphql-actix-web |
| Metrics | Prometheus and OpenTelemetry plugins | Community crates | Community crates |
| First release | 2025 | 2021 | 2017 |
Throughput
Hello-world requests per second, the median of five 15-second wrk runs in a
24 vCPU Linux container, measured with tako-rs 2.4.0 in October 2026:
| Framework | Loopback, 1,000 connections | Server-bound | Pipelined |
|---|---|---|---|
| Tako per-thread | 1,842,063 | 612,091 | 15,033,668 |
| Actix Web | 1,786,640 | 570,865 | 12,806,477 |
| Tako | 1,401,625 | 483,526 | 11,512,467 |
| Tako + jemalloc | 1,386,954 | 469,807 | 10,853,271 |
| Axum | 1,132,259 | 389,844 | n/a |
Tako's default server runs on Tokio's work-stealing runtime, like Axum, and
serves about 24% more requests at 1,000 connections and when the server is the
bottleneck. The thread-per-core per-thread server runs one runtime per
worker, like Actix Web, and serves 3% more requests than Actix Web on loopback,
7% more server-bound, and 17% more pipelined. Axum has no pipelined number
because axum::serve leaves TCP_NODELAY off. A hello-world route measures
framework overhead, not application performance; read the
benchmark methodology before drawing conclusions.
When to choose which
Choose Axum when:
- you want Tower middleware and the widest set of third-party integrations;
- the service is mostly REST or JSON over HTTP/1.1 and HTTP/2;
- a small core that you compose yourself is the goal.
Choose Actix Web when:
- you want the longest production track record among Rust web frameworks;
- top hello-world throughput on the default setup matters most.
Choose Tako when:
- one process serves HTTP next to HTTP/3, WebSocket, SSE, gRPC, or raw TCP/UDP, and those transports should share routing, middleware, and signals;
- you want auth, sessions, CSRF, rate limiting, idempotency, and metrics without assembling them from separate crates;
- you want Compio or a thread-per-core server without leaving the framework.
Know the trade-offs before choosing Tako:
- The community is smaller and there are fewer third-party integrations. Tower layers do not plug in.
- The API still moves. Versions 2.1, 2.2, and 2.3 had breaking changes, each with a migration guide.
- The minimum supported Rust version is 1.95.
Porting an Axum service
Handlers, extractors, and path syntax carry over almost unchanged. Coming from Axum maps each Axum building block to its Tako equivalent.
Last updated on
Design philosophy
The principles behind tako — one service many transports, one model two runtimes, primitives included, and performance knobs when they matter.
Transports
Every Tako transport — HTTP, HTTP/3, WebSocket, WebTransport, SSE, gRPC, raw sockets, and PROXY protocol — with runtime and feature-flag support.