Short version for the impatient: if my project is a long-lived service with a clean schema I own, I reach for Diesel. If I’m gluing together a bunch of existing tables, writing analytical queries, or shipping something this week, I reach for sqlx. I’ve shipped both, regretted both at different times, and I’ll explain how I actually decide between them now.
I avoided picking sides on this for years. Every Rust thread on the subject turns into a religious war about compile-time safety, and I find the abstract argument boring. What I care about is which one gets out of my way on a Tuesday afternoon when I’m two coffees in and need to ship a feature. After running both in production for the better part of two years, I finally have an opinion that isn’t just vibes.
What’s actually different between them in 2026
The headline difference hasn’t changed: Diesel is a full ORM with a typed query builder, and sqlx is a SQL-first crate that checks your raw queries against a live database at compile time. Both check your queries before you ship. They just check different things.
Diesel models your tables as Rust types in a generated schema.rs. Your queries are Rust expressions (users.filter(name.eq("Qasim")).load(&mut conn)), and the compiler will refuse to build code that asks for a column that doesn’t exist or compares a Text to an Integer. The trade-off is that you write Rust, not SQL, and the macros that make it all work can produce error messages that need a coffee break to decipher.
sqlx flips the model. You write actual SQL inside query! and query_as! macros, and during cargo build it connects to a real database (via DATABASE_URL or a saved offline cache) and validates the query. If you typo a column name, the build breaks. If the inferred Rust type doesn’t match the column, the build breaks. But you’re writing SQL, not learning a DSL.
I’ve watched at least four people learn Diesel in 2026 and the same thing happens every time: they hit a five-line type error from diesel::insert_into(...).values(...) and they want to flip a table. I get it. The errors have gotten better since the 2.x era, but the cognitive load of holding the type system in your head while you write a query is still real.
The day I switched a service from Diesel to sqlx
Last September I had a Diesel service that talked to a Postgres schema I didn’t own. Another team controlled migrations. They added a column, dropped a constraint, renamed something, and my schema.rs was suddenly lying. Regenerating it broke five compile units, two of which I didn’t want to change. I spent half a day rewriting query builder calls that were perfectly fine SQL underneath.
That night I rewrote the service in sqlx. About 1,800 lines of code became roughly 1,200, mostly because the query builder ceremony evaporated. The .sqlx offline cache moved into the repo, CI got faster, and when the other team renamed a column the next month, the build failed at exactly the query that used it. No regenerated schema.rs. No cascading type errors. I had to fix one line.
That experience didn’t make me a sqlx zealot. It made me realise that I’d been using the wrong tool for that particular shape of problem. Diesel is brilliant when you own the schema. The moment you don’t, the ergonomics flip.
Here’s roughly what the same query looks like in each. Diesel:
use diesel::prelude::*;
use crate::schema::users::dsl::*;
let active: Vec<User> = users
.filter(active.eq(true))
.filter(created_at.gt(cutoff))
.order(created_at.desc())
.limit(50)
.load(&mut conn)?;
And sqlx:
let active = sqlx::query_as!(
User,
r#"
SELECT id, email, created_at
FROM users
WHERE active = $1 AND created_at > $2
ORDER BY created_at DESC
LIMIT 50
"#,
true,
cutoff,
)
.fetch_all(&pool)
.await?;
Both are checked at compile time. The Diesel version refactors more cleanly if I change users later. The sqlx version is faster to write and easier for someone who reads SQL but not Diesel to review. Pick your poison based on which kind of change is more likely in your codebase.
How I actually pick now
After enough projects I’ve settled on three questions I run through before starting.
First: do I own the schema? If a Rust team controls the migrations and the schema is going to evolve with the application code, Diesel earns its keep. Codegen stays honest, refactors propagate, and the typed query builder pays for itself the third time someone renames a column. If another team or another service owns the schema, sqlx wins by a wide margin, because schema drift becomes a “fix the failing query” problem instead of a “regenerate the world” problem.
Second: how SQL-heavy is the workload? CRUD apps with a few joins are happy with either. Reporting queries, recursive CTEs, window functions, and weird JSONB shenanigans are miserable in Diesel. The query builder is great until you need a LATERAL join with a correlated subquery, at which point you fight the DSL while the SQL version sits in a .sql file laughing at you. sqlx lets you keep that SQL as SQL and still type the columns.
Third: what’s the team profile? If I’m working with backend engineers who write SQL in their sleep, sqlx is the lower-friction choice, because they can read and audit queries without learning a Rust DSL. If the team is mostly application engineers who’d rather model in Rust types, Diesel’s compile-time guarantees feel like a safety net rather than a tax. There isn’t a right answer here; there’s a right answer for your specific group.
For service work I usually default to sqlx now. For libraries and tools I publish on crates.io that other people will read and modify, Diesel’s typed builder makes the code more self-documenting. I keep both in my toolbox. That’s similar to how I think about Rust web frameworks: the right pick is shaped by who’s going to maintain the code, not by Twitter consensus.
Things people get wrong about each one
A few opinions I’ve changed my mind on.
Diesel isn’t slow. The “Diesel makes my builds painful” reputation comes mostly from the proc-macro heavy crate graph and the codegen for big schemas. On a clean modern machine with cargo caches warm, the marginal cost is small. If your build is slow, sqlx with query! macros isn’t necessarily faster, because every query in your codebase runs through the database connection at compile time too. There’s no free lunch.
sqlx is not just “raw SQL with no safety”. The compile-time check is a real check. It validates the query parses, the columns exist, the types match, and (in the query_as! flavour) maps directly to your struct. The catch is that it needs either a running database or a committed .sqlx offline cache, and getting the offline cache to play nicely in CI took me an embarrassingly long afternoon when I first set it up. Worth doing once.
Both crates handle migrations. Diesel ships diesel_cli with up.sql/down.sql pairs. sqlx ships sqlx-cli with simple forward migrations and optional reversibles. I prefer sqlx’s migration UX, but Diesel’s is more battle-tested. Neither is going to win you the migrations argument with your DBA.
Connection pooling is the same conversation either way. Both use deadpool or bb8 (or sqlx’s built-in pool) under the hood, and both will fall over the same way if you forget to bound concurrency in a high-throughput service. The Rust async runtime story is the actual bottleneck, not the library.
A thing you can do this week
Pick one route in a side project. Write the same query in both Diesel and sqlx, including the Cargo.toml deltas, the connection setup, and the error handling. Time yourself. Note which one made you reach for the docs and which one you wrote without thinking. Do it again a month later and see if your answer changes.
If you want to skip ahead, the sqlx README’s “Compile-time verification of SQL queries” section and the Diesel “Getting Started” guide will get you to a working query in under thirty minutes each. After that, the question is whether you like the feel of each one. That’s the part nobody else can decide for you. I write about this kind of pragmatic tooling decision a lot in my work and notes, and the answer is almost always “it depends on the shape of the problem”, which I know is unsatisfying. But it’s honest, and so is the choice between these two libraries.
