SQLx Talk @ Svix SF Rust Meetup, 2025/12/04

[abonander]

I was recently invited by Svix to speak at their new Rust meetup hosted at their San Francisco office.

I talked about SQLx, giving a brief history, going over our current challenges and talking about plans for the near future.

The talk has been posted as a video on Svix's YouTube channel, along with talks from two other speakers (mine is from 00:00 to 33:26): https://www.youtube.com/watch?v=ZC7UcfBp2UQ

Slides: https://docs.google.com/presentation/d/151MAto59wZ5-0nRqrOTdnTmlr_ZvLgT9esjem41MQi0/edit?usp=sharing

Discuss on Reddit: https://www.reddit.com/r/rust/comments/1poilot/sqlx_talk_svix_sf_rust_meetup_20251204/?

Links, Notes, and Errata

About Me

• Proof that I'm an OG:
  • First /r/rust post: https://www.reddit.com/r/rust/comments/29ol18/problems_using_dlist/
  • First PR to rust-lang: hash: HashMap, custom key types, HashSet, and SmallIntMap rust-lang/rust-by-example#205
• Implement #[proc_macro_attribute] rust-lang/rust#38842
• Implement function-like procedural macros ( #[proc_macro]) rust-lang/rust#40129

Reasons We Created SQLx

• #[diagnostics] RFC by author of Diesel: The #[diagnostic] attribute namespace rust-lang/rfcs#3368
• tokio-diesel created by Ryan Leckey (@mehcode): https://crates.io/crates/tokio-diesel
• diesel-async first-party async support for Diesel (0.1.0 released 2022/09/27): https://crates.io/crates/diesel-async

Cancellation: Rust's "Million-Dollar Mistake"?

• Tokio has an excellent guide on how async works, including an example of how async is desugared: https://tokio.rs/tokio/tutorial/async#async-fn-as-a-future
  • Unfortunately, it doesn't really show the self-referential nature of the desugared structure. The problem is, this is inherently impossible to demonstrate in safe Rust code and it gets complicated fast for any non-trivial example.
• tokio::sync::Notify is a great example of how intrusive waitlists in async work. It's used internally as a building-block for cross-task synchronization all throughout Tokio.
  • The equivalent for Smol/async-std is the event-listener crate, though it only becomes intrusive if you use the listener!() macro, otherwise the nodes are heap-allocated.
• For a great example of how poorly cancellation is documented, see the Cancellation and Cancellation Safety chapter of the official async Rust book (which has never actually been finished). Part of the problem is that cancellation really seems to have been something most everyone else involved in building the async/await ecosystem was already aware of and took for granted, so there was little impetus to document it properly.
• See std: Rename thread::catch_panic to panic::recover rust-lang/rust#29937 and the linked RFC PRs for discussions about std::panic::catch_unwind() (originally panic::recover()) being made safe and the bounds added to it. To be fair, what the team was worried about was making catch_unwind() too easy to reach for as an error handling mechanism, so the API was deliberately designed to be annoying. However, the striking similarity between panic-safety and cancellation-safety, and the massive difference in concern about one over the other, was just something I wanted to point out.

It's Actually a Feature, I Swear

• Javascript's AbortController: https://developer.mozilla.org/en-US/docs/Web/API/AbortController
  • StackOverflow: javascript - is it possible to force cancel a promise
• C#'s CancellationToken: https://learn.microsoft.com/en-us/dotnet/api/system.threading.cancellationtoken?view=net-10.0
• Go's context.WithCancel(): https://pkg.go.dev/context#example-WithCancel
  • This article pretty well sums up what I think about Go: https://en.uncyclopedia.co/wiki/Go_(programming_language)
  • The article on Rust is also pretty funny, though: https://en.uncyclopedia.co/wiki/Rust_(programming_language)
• Hyper serving an HTTP/1.1 connection will likely only notice the client has closed the connection when it next goes to read or write, but when serving HTTP/2, the client can send an RST_STREAM frame at any time to cancel the request.
  • It doesn't need to abort the task, though, it just exits with an error. But this still cancels the handler future regardless.
  • Thinking about this, I realized why we might not have run into this in our dogfooding usage at LaunchBadge. We hosted the vast majority of our applications using Google Kubernetes Engine, which uses HTTP/1.1 to connect to the backend application by default. So any dropped connections won't be observed until the framework goes to send the response, after the handler has returned. It would only be observable by user code in a streaming response, which was rare in our code.
• Other major sources of cancellations I forgot to mention:
  • tokio::time::timeout() cancels the Future if the timeout elapses.
  • tokio::select!() cancels the branches that haven't completed yet.
  • tokio_util::sync::CancellationToken::run_until_cancalled() does exactly what it says on the tin.

One of Many

• PR with this fix: Correctly ROLLBACK transaction when dropped during BEGIN. #3980
  • Available in the 0.9.0-alpha.1 release

Solution: Spawn More Tasks

• Postgres: Move io to background task. #3891

Null Safety from Thin Air

• For a great example of why I don't like MySQL, see:

  sqlx/sqlx-mysql/src/collation.rs

  Lines 1 to 37 in e8384f2

  	// One of several questionable design decisions in MySQL is the choice to conflate
  	// *how stored data is sorted* with the character encoding used over the wire.
  	//
  	// The documentation for `Protocol::HandshakeResponse41` implies that
  	// the lower 8 bits of the collation ID may be used to uniquely identify the character set:
  	// https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase_packets_protocol_handshake_response.html
  	//
  	// However, this isn't at _all_ true in practice. Collation IDs are assigned without any apparent
  	// rhyme or reason, mostly just sequential with unexplained gaps. Masking the collation ID with 0xFF
  	// doesn't actually tell you anything meaningful, except obviously for collation IDs under 256
  	// which just gives you the same collation ID again.
  	//
  	// Hanlon's razor would suggest they just forgot that they told clients they could do this.
  	// Occam's razor suggests no one ever bothers to set the connection charset/collation this way,
  	// and they all just default to `latin1_swedish_ci` (8), `utf8mb4_general_ci` (45),
  	// or `utf8mb4_0900_ai_ci` (255).
  	//
  	// This would seem to mean that if we want to be *sure* of the character encoding of a given column,
  	// we have to reference the _full_ catalog of collations. Because new ones are added occasionally,
  	// we can't just assume a collation we don't recognize is UTF-8 as that's not always the case.
  	//
  	// This is especially true when we include MariaDB because they've started creating
  	// their *own* collations, and even character sets, separately from MySQL.
  	//
  	// Awesome, right?
  	//
  	// However, as long as `character_set_client` and `character_set_results` are set correctly,
  	// we can assume that any non-binary collation is a valid string, because the server will transcode.
  	// As it turns out, the collation specified in the `Protocol::ColumnDefinition`
  	// is *purely* informational. It has no bearing on what's sent over the wire except for `binary` (63),
  	// which is never transcoded.
  	//
  	// So at the end of the day, none of this matters anyway! To know if a column is a string or not,
  	// we merely need to check if it's not `binary` (63). If the protocol was just a *bit*
  	// better documented, it would have saved me literally six hours spent figuring this out.
  	//
  	// Thanks, MySQL.

The Lengths We Go to, to Not Parse SQL

• Postgres does give us the original table name for a column in the prepared statement metadata. What we get over the wire when we prepare a statement is the RowDescription message.
  • We parse the EXPLAIN output in this method.

I Dunno, Maybe Parsing SQL Would Be Easier

• The EXPLAIN parsing for SQLite is in this file. This is code is especially arcane and difficult to maintain; I barely understand what's going on here, myself. It was originally written by @mehcode and only one or two other brave souls, namely @tyrelr, have dared to venture into that quagmire. One of the happiest days in my career will be the day I get to delete this file.

It's Far from Perfect

• One of the more recent reports showcasing this fragility: sqlx::query! macros do not work with TimescaleDB Hyperfunctions due to query parts being optimized away #4019
• We also can't introspect expressions in general.

Lack of Interaction with #[derive(FromRow)]

• This is such a long-standing issue, and it comes up so regularly, that I literally have the issue number memorized: query_as! macros do not use FromRow #514
• I've also since thought of a major change I can do to the FromRow trait and derive: currently, the code generated by #[derive(FromRow)] looks up columns by name and type-check them for every single row, which is obviously a performance bottleneck. It's also completely unnecessary because the shape of the result-set is fixed once it starts coming in, so I want to separate this so one method looks up the column names and resolves them to offsets at the start of the result-set, and then another method uses those pre-resolved offsets to decode each row.
• It's at this point that one of my hosts lets me know I've gone over my allotted 20 minutes, so from this point on I'm rushing through because there's two other speakers after me. To be honest, I should have rehearsed this talk but I didn't.

What, Postgres Ain't Good Enough for You?

• I was hoping the slide title would get a laugh. 😞
• The SQLx Pro initiative is referring to a previous announcement we made alongside the 0.7.0 release: Update: Our Plans Regarding MSSQL and Other Proprietary Drivers #1616
  • These plans have long since been defunct because we didn't want to put in all that effort if no one was interested, and as Ryan told me, we got basically zero serious inquiries.
  • More recently, I had considered going to work full-time on SQLx by being funded through Github Sponsors, but I was concerned I wouldn't earn enough from that to cover my living expenses, and the ClickHouse opportunity was too fitting to pass up.
• sqlx-exasol: https://github.com/bobozaur/sqlx-exasol

"SQLx is Slow?"

• https://www.techempower.com/benchmarks
  • Notice how infrequently these are run, as well. Almost two years elapsed between the last two rounds (!).
  • Actix-Web appeared in previous rounds, but not in the most recent one for some reason.
  • Clicking the link to the Continuous Benchmark Results times out for me.
• I get so tired of seeing this benchmark mentioned:
  • https://www.reddit.com/r/rust/comments/1jnd5bh/sqlx_slows_down_axum_by_30x/
  • SQLx is significantly slower than postgres / tokio-postgres #2436
  • https://www.reddit.com/r/rust/comments/1btdrc1/does_sqlx_really_have_more_overhead_in_rust_than/kxmc70j/

That Benchmark Cheats, Actually (Kinda)

• Source code for the benchmarks:
  • Axum with tokio-postgres : https://github.com/TechEmpower/FrameworkBenchmarks/blob/R23/frameworks/Rust/axum/src/main_pg.rs
    • common::serve_hyper() is what starts the separate runtimes.
    • Each query is explicitly prepared ahead of time, but I don't think that makes a huge difference. SQLx prepares and caches the query on each connection, so the first call might be slower but the rest should be fast. There's probably some optimizing to be done in the cache lookup though.
  • SQLx: https://github.com/TechEmpower/FrameworkBenchmarks/blob/R23/frameworks/Rust/axum/src/main_sqlx.rs
  • Deadpool:https://github.com/TechEmpower/FrameworkBenchmarks/blob/R23/frameworks/Rust/axum/src/main_pg_pool.rs
• Separate current-thread runtimes, sockets, and accept loops is the same execution model Actix-Web uses.
  • The goal is to reduce or eliminate contention between threads, which I suspect is where a lot of the speedup comes from. Actix Web was the performance king in Rust webdev for a long time because of this strategy (it also used a lot of internal unsafe which used no synchronization because there was no cross-thread communication).
• The lack of support for transactions (which requires mutable access to the tokio_postgres::Client) is a significant part of what makes this benchmark unrealistic, in my opinion. Any time you're doing more complex mutations, or you have a fetch coupled with a store, you should be using a transaction to have a coherent view of the data, e.g.: https://github.com/launchbadge/realworld-axum-sqlx/blob/f1b25654773228297e35c292f357d33b7121a101/src/http/profiles.rs#L101
• The multi-threaded runtime of Tokio is designed around work stealing, which lets idle worker threads steal extra tasks from overloaded worker threads. But this strategy shows little benefit when all the threads are doing relatively similar work (like they're all answering requests to the same route), because all CPUs are loaded relatively equally.
• I wanted to conclude this slide by saying that this benchmark does suggest that there's a lot of performance being left on the table here by the default Tokio configuration, and that perhaps it's worth investigating whether the multi-threaded runtime should give each worker thread its own I/O and timer driver.

It's Not That Bad, Really

• https://github.com/diesel-rs/metrics
  • Source code is in the main Diesel repo: https://github.com/diesel-rs/diesel/tree/main/diesel_bench
• As you'll see in the previously linked discussions, I point people to these metrics all the time. I think they're a lot more fair, largely because they test specifically the SQL client with little else in the way, and it's easy to show that it's unlikely that we've manipulated these in our favor at all because they're published by a "competitor".
  • If you look, you'll see the TechEmpower benchmarks aren't particularly friendly to Diesel, either. However, I was unable to find the source for roa-diesel, which is the highest-scoring benchmark for them in Round 23. There is no framework named roa that I could find in the source.
  • Addendum: found it. I've updated the other source links with the R23 tag for a fair comparison. It uses roa-diesel which wraps regular blocking calls with .spawn_blocking() instead of using diesel-async (which wasn't available yet when this benchmark was created, and it apparently was never updated).

Rebuilding sqlx::Pool from the Ground-Up (#3582)

• WIP pool changes #3582
• I came up with a strategy for splitting the pool into shards, one assigned to each worker thread, which I was really excited about: d542099
  • However, this actually performed worse than the existing implementation. Part of the problem is the number of worker threads that get spawned, especially on modern CPUs, can approach or exceed the max_connections, so each shard essentially becomes a really inefficient Mutex for a single connection.
• A compounding issue is that it's really hard to profile async code, since perf won't tell you how long a task was sitting at a .await point. There isn't a ton of advice or tools out there yet to help with this. I'd actually love to get some suggestions on how to approach this.

Going into 2026

• CHANGELOG entry for 0.9.0-alpha.1: https://github.com/launchbadge/sqlx/blob/main/CHANGELOG.md#090-alpha1---2025-10-14
• https://github.com/transact-rs/

Don't You Work for a Database Company, Now?

• Fun fact: this is one of the only job applications I've ever written a cover letter for. To be fair though, it's one of two jobs I've ever applied for and actually gotten hired as a result. The rest of my jobs I got through networking or cold offers.
• Task to replace Serde in clickhouse-rs: Replace/supplement Serde serialization with bespoke traits ClickHouse/clickhouse-rs#336
• The comment in the screenshot: [Database] ClickHouse #533 (comment)
• The fact that ClickHouse is a columnar database isn't really a blocker, surprisingly. It has a row-major wire format which is actually what's used by clickhouse-rs.
• clickhouse-rs and related internal projects is where I've spent most of my time lately. My arrangement with ClickHouse is similar to previous employers: I can work on SQLx as time permits, but there isn't really any dedicated time blocked out for it. I'm hoping that as clickhouse-rs stabilizes and the future SQLx ClickHouse driver shows a return in investment, that I'll be given dedicated time to work on it.

Q&A

• ClickHouse Careers: https://clickhouse.com/company/careers
• ClickHouse Community Slack (come say hi in #rust!): clickhouse.com/slack
• SQLx Discord: https://discord.gg/uuruzJ7

[titaniumtraveler]

Note that you can directly link to a specific time by adding a query parameter of the timestamp measured in seconds: 33min 26s -> 2006 https://www.youtube.com/watch?v=ZC7UcfBp2UQ&t=2006s

[abonander]

My talk starts at 00:00 and ends at 33:26. Sorry, perhaps that wasn't clear.

[titaniumtraveler]

I guess then it is https://www.youtube.com/watch?v=ZC7UcfBp2UQ&t=0s lmao