SQLx 0.9.0 Released!

[abonander]

This release announcement was too big to fit in one Discord message, and not everyone checks Discord anyway, so I've decided to try posting it here instead. Please feel free to post any questions or feedback here as well.

For details, see the CHANGELOG entry: https://github.com/launchbadge/sqlx/blob/main/CHANGELOG.md#090---2026-05-06

(Note: I accidentally published this release from my pre-squash release branch instead of main, but I tagged the release commit on main. The only difference is an update to an example in the README.)

Important Announcements

New Github Organization

Shortly after this release is published, the SQLx repository will be transferred to a new GitHub organization:
https://github.com/transact-rs/

This is because SQLx has not been owned or maintained by LaunchBadge, LLC. for a few years now, and has since been
informally transferred to the collective ownership of its principal authors. Moving the repository to a new
organization makes this change more clear, and also allows for potentially inviting outside collaborators.

Cargo.lock Removed from Tracking

The Cargo.lock has been removed from tracking in Git. CI should now always test with the latest versions of
all dependencies by default, alongside our pass that checks with cargo generate-lockfile -Z minimal-versions.

This should eliminate the need for any PRs that update dependencies to also update Cargo.lock or
contend with an endless stream of merge conflicts against it.

N.B. cargo install --locked sqlx-cli will no longer work. However, cargo install sqlx-cli has always
used the latest dependencies by default, ignoring the lockfile, so most users should not be affected. For users
requiring reproducible builds, consider maintaining your own lockfile instead; historically, we only ran cargo update
sporadically, so relying on SQLx's lockfile offered few guarantees anyway.

See the manual page for cargo install for details.

Release Highlights (see CHANGELOG for full release notes)

This release adds support for the smol and async-global-executor runtimes as a successor to the deprecated async-std crate.

It adds support for a new sqlx.toml config file which makes it easier to implement multiple-database or multi-tenant setups, allows for global type overrides to make custom types and third-party crates easier to use, enables extension loading for SQLite at compile-time, and is extensible to support so many other planned use-cases, too many to list here. There are links to the new example projects demonstrating this feature in the CHANGELOG.

Additionally, this release replaces the &str parameter of the query*() family of functions with a generic parameter implementing the new SqlSafeStr trait, which signals a query string that is safe from SQL injections. By default, SqlSafeStr is only implemented for &'static str which, barring niche cases like String::leak(), should only be constant string values. Other string types may now be passed wrapped in AssertSqlSafe(..) which is designed to be easy to spot during code review. This finally allows passing an owned String, which should make it possible to return a pre-built Query from a function as Query<'static, DB>.

Direct calls to Executor, which have been broken by the switch to SqlStr, should be replaced with sqlx::raw_sql("<SQL>").execute(...) which was introduced back in 0.7.4.

libsqlite3-sys is now specified using a version range which should make it much more friendly to link SQLx with other crates that depend on it, like rusqlite. The maximum of the range may now be increased in any backwards-compatible release. The minimum of the range may only be increased in major releases. If you have libsqlite3-sys in your dependencies, Cargo should choose a compatible version automatically. If otherwise unconstrained, Cargo should choose the latest version supported.

New non-default features have been added, corresponding to conditionally compiled SQLite APIs:

• sqlite-deserialize enabling SqliteConnection::serialize() and SqliteConnection::deserialize()
• sqlite-load-extension enabling SqliteConnectOptions::extension() and ::extension_with_entrypoint()
• sqlite-unlock-notify enables internal use of sqlite3_unlock_notify()

This is mainly to allow linking a pre-built SQLite binary that has omitted these features.

Also included should be the final fix for the pesky bug with the MySQL driver complaining about various collations not being compatible with strings. It turned out to be a misinterpretation of the protocol docs (which are quite hit-or-miss). We now treat all string data as compatible with String, etc., unless it uses the binary collation (ID 63). We also no longer pass COLLATE utf8_general_ci during startup, letting the server choose the appropriate default collation. For those interested, see the comment in sqlx-mysql/src/collation.rs.

[kamikaze]

wow, what a great job done! thanks a lot!

[marcalj]

Congratulations and thanks for the great job!

[JarvisCraft]

Congratulations on the release!

---

While I see your reasoning for Cargo.lock removal, its removal actually brings more problems than it solves

It makes dependencies volatile and hard to debug, making developer experience irreproducible and flacky.

Even more, it brings problems to distros packaging tools like sqlx-cli which will now have to re-generate Cargo.lock file themselves breaking/complicating automations. For instance, nixpkgs will now have to genreate and store lockfile themselves in addition to its hash (which always was a thing).

After all, even official docs suggest committing Cargo.lock both for libraries and binaries (which this repo is both): https://blog.rust-lang.org/2023/08/29/committing-lockfiles/

This should eliminate the need for any PRs that update dependencies to also update Cargo.lock or
contend with an endless stream of merge conflicts against it.

This sounds like the wrong way to fix the real issue: to me it feels like PRs should just not touch the lock file and rely on master one unless explicitly adding new dependencies. Lock file itself could be upgraded automatically or by hand.

Considering this, I ask you to reconsider this decision.

[JarroVGIT]

I am also surprised by this, especially with the endless stream of supply chain attacks that we’ve seen recently. This move would make this repo less resilient against that, I’d reckon?

[abonander]

The problem is that I would literally never remember to run cargo update, and often in the past when I'd do it as part of publishing a release, it would surface random new problems with dependency resolution that I'd then have to deal with.

Case in point, the following PR was a massive headache to debug and it was triggered by an innocuous-looking dependency update: #4173

Though as it turns out, it was actually surfacing a bug in our TLS implementation so it may have been a blessing in disguise... I dunno. If we weren't maintaining a Cargo.lock, that would have started failing much sooner. I still don't know exactly what changed that caused it to surface, but I assume it was some innocuous behavior change in one of the runtimes or RusTLS.

I've maintained repositories that have Dependabot, and I find that it just generates a lot of extra noise, or it's just not active enough to be that useful. I think you can tune how often it opens PRs, but in most cases I've seen, it's configured to only open them when one of your dependencies has an advisory published against it. So you're just trading off between a lot of extra noise and review burden, or having stale dependencies anyway.

The idea of adding another CI pass that tests with updated dependencies begs one question: do we just check that the project compiles with latest dependencies, or do we actually test everything? The former offers very little in the way of guarantees, the latter would double our job count. I don't really like either prospect.

And then there's the fact that cargo install ignores lockfiles by default, so 99% of users don't even benefit from us maintaining one in the first place. If Cargo changed that behavior, it would probably make more sense to keep a lockfile around. I would only be comfortable recommending cargo install --locked if the lockfile was kept reasonably up to date.

This sounds like the wrong way to fix the real issue: to me it feels like PRs should just not touch the lock file and rely on master one unless explicitly adding new dependencies. Lock file itself could be upgraded automatically or by hand.

That's generally what people do. It's just a lot of PRs against this project tend to touch dependencies at one point or another because of how large it is. And if I merge one PR that touches the Cargo.lock, I've now gotta chase down all the others that touch it and get them to rebase and fix conflicts.

[abonander]

As far as supply-chain attacks go, I'm not sure there's any perfect substitute for doing your own due diligence. Using our Cargo.lock, you're essentially just trusting me and a bunch of random contributors to have done that for you.

[abonander]

I want to add that the decision isn't set in stone by any means, but the problem is that there really isn't a manual or consistent conventions for how to do this in Rust. Even the blog post linked above mainly mentions concerns about MSRV, which resolver v3 has mostly taken care of. And neither Diesel nor Tokio maintain a lockfile, though rust-postgres does, surprisingly.

I do think we should also be looking to upstream for mitigations/solutions to supply-chain attacks (e.g. adding 2FA, code signing to crates.io), though I'm keenly aware that development bandwidth is extremely limited there. It seems the Rust project as a whole is in dire need of more support and resources.

[JarroVGIT]

Thanks for the extended explanation! Let me stress that I support whatever you decide, especially if it lessens the workload for you. This is a foundational crate and I am very grateful for the work you put in!

I am surprised to learn that neither Tokio nor Diesel maintain a lockfile, thanks for pointing that out.