Axum vs Actix Web

Axum and Actix Web are the two Rust web frameworks most teams shortlist for a new API. Both run async handlers on Tokio and use Serde for JSON. They differ in how routes are declared, how middleware is written and which crates they share code with, and those differences matter more as the service grows.

The main differences:

• Axum declares routes with a Router and plain async functions, while Actix Web usually declares them with attribute macros such as #[post].
• Axum uses Tower layers for middleware, while Actix Web has its own Transform trait.
• Actix Web starts one single-threaded runtime per worker, while Axum runs on a multi-threaded Tokio runtime.
• Actix Web ships first-party crates for sessions, CORS, multipart and static files, while Axum relies on the wider Tower and Hyper ecosystem.

Axum vs Actix Web at a glance

Axum: functions and extractors

An Axum handler is an async function whose arguments are extractors. The Axum 0.7 documentation describes how the router checks at compile time that each handler's state matches what the router provides. This signup endpoint takes a SQLx pool through State:

use axum::{extract::State, http::StatusCode, routing::post, Json, Router};
use serde::Deserialize;
use sqlx::PgPool;

#[derive(Deserialize)]
struct Signup {
    email: String,
}

async fn create_user(
    State(pool): State<PgPool>,
    Json(req): Json<Signup>,
) -> Result<StatusCode, StatusCode> {
    sqlx::query("INSERT INTO users (email) VALUES ($1)")
        .bind(&req.email)
        .execute(&pool)
        .await
        .map_err(|_| StatusCode::INTERNAL_SERVER_ERROR)?;
    Ok(StatusCode::CREATED)
}

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let pool = PgPool::connect(&std::env::var("DATABASE_URL")?).await?;
    let app = Router::new()
        .route("/users", post(create_user))
        .with_state(pool);
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await?;
    axum::serve(listener, app).await?;
    Ok(())
}

Compiler errors for a handler with extractors in the wrong order can be hard to read, and #[debug_handler] from axum-macros improves them. Axum 0.8 changed path parameters from /:id to /{id}, so check which version an example targets.

Actix Web: macros and workers

Actix Web starts one worker per available CPU thread by default, and the Actix server documentation explains that each worker gets its own application instance. Shared state therefore goes through web::Data, which wraps it in an Arc:

use actix_web::{post, web, App, HttpResponse, HttpServer, Responder};
use serde::Deserialize;
use sqlx::PgPool;

#[derive(Deserialize)]
struct Signup {
    email: String,
}

#[post("/users")]
async fn create_user(pool: web::Data<PgPool>, req: web::Json<Signup>) -> impl Responder {
    match sqlx::query("INSERT INTO users (email) VALUES ($1)")
        .bind(&req.email)
        .execute(pool.get_ref())
        .await
    {
        Ok(_) => HttpResponse::Created().finish(),
        Err(_) => HttpResponse::InternalServerError().finish(),
    }
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let url = std::env::var("DATABASE_URL").expect("DATABASE_URL");
    let pool = PgPool::connect(&url).await.expect("connect");
    HttpServer::new(move || {
        App::new()
            .app_data(web::Data::new(pool.clone()))
            .service(create_user)
    })
    .bind(("0.0.0.0", 8080))?
    .run()
    .await
}

Forgetting to register app_data compiles fine and fails at request time with a 500, which is a common runtime surprise for new Actix users.

Performance

Actix Web has long ranked among the fastest frameworks in the TechEmpower benchmarks, and Axum usually lands close to it. Both handle far more traffic than most APIs see, so database queries and serialization decide real latency, and ergonomics and ecosystem fit matter more.

Adding infrastructure to either framework with Encore

Encore combines the Rust service you already have with infrastructure declared as static values in the same crate. It is an infrastructure SDK added as the encore-dev crate, not a framework you switch to. Postgres databases, Pub/Sub topics, object storage buckets, Redis, cron jobs and secrets become declarations that Encore discovers and provisions, and the handlers use them without a pool in State.

The signup endpoint with Encore, written for Axum 0.7:

use axum::{http::StatusCode, routing::post, Json, Router};
use encore::pubsub::Topic;
use encore::storage::postgres::Database;
use serde::{Deserialize, Serialize};

static DB: Database = Database::new("users").migrations("./migrations");
static SIGNUPS: Topic<Signup> = Topic::new("signups");

#[derive(Serialize, Deserialize)]
struct Signup {
    email: String,
}

async fn create_user(Json(req): Json<Signup>) -> Result<StatusCode, StatusCode> {
    DB.execute("INSERT INTO users (email) VALUES ($1)", &[&req.email])
        .await
        .map_err(internal)?;
    SIGNUPS.publish(&req).await.map_err(internal)?;
    Ok(StatusCode::CREATED)
}

fn internal(_: encore::Error) -> StatusCode {
    StatusCode::INTERNAL_SERVER_ERROR
}

#[tokio::main]
async fn main() {
    encore::initialize();
    let app = Router::new().route("/users", post(create_user));
    let addr = std::env::var("ENCORE_LISTEN_ADDR").unwrap_or("0.0.0.0:8080".into());
    let listener = tokio::net::TcpListener::bind(addr).await.unwrap();
    axum::serve(listener, app)
        .with_graceful_shutdown(encore::shutdown::signal())
        .await
        .unwrap();
}

The DB and SIGNUPS statics do not depend on the router, so an Actix Web handler can call DB.execute and SIGNUPS.publish the same way.

encore run starts Postgres locally and applies the migrations, along with the topic and any buckets, and the CLI reference covers encore test, which gives each test its own migrated database.

A deploy provisions the declarations in your own AWS or GCP account.

A coding agent that needs a queue for a new handler writes the Topic::new static in the same diff and runs it under encore run before anyone reviews it. Cloud access sits with Encore's IAM role, not the agent, and the AI integration guide explains how to give an agent Encore's conventions.

Rust support is in beta, and you can request access.

Try Encore →

How to choose

• Axum for most new APIs, especially when you want Tower middleware and compile-time checked state.
• Actix Web when you want many first-party crates and a long production record.

Either works with Encore when you want Postgres and Pub/Sub declared in Rust and provisioned in your own cloud account.

Related guides

• Axum vs Actix Web vs Rocket
• How to add a Postgres database to an Axum API
• Best Rust web frameworks in 2026
• How to deploy an Axum app to AWS
• How to add cron jobs to an Axum app
• Best Rust framework for building AI agents