SQL stays in charge
SQLx is for Rust developers who like their database and do not want an abstraction to pretend SQL is an implementation detail. Queries remain ordinary SQL strings. The library supplies async connections, a pool, prepared-statement caching, row streaming, transactions, migrations, and type conversion around them. PostgreSQL, MySQL, MariaDB, and SQLite are supported, while the Any driver can select a backend from the connection URL at runtime.
The result sits between a bare driver and an ORM. You write joins, database-specific syntax, and performance-sensitive statements yourself. SQLx handles transport and maps rows into Rust values or structs. This gives experienced SQL users direct control and avoids learning a second query language. It also leaves schema design and most higher-level data modeling with the application team.
Runtime and TLS choices are feature flags. Tokio and async-std are supported, with native TLS and several rustls configurations. Database drivers and integrations for common Rust types are also optional. This keeps unused backends out of the final dependency graph, though the feature list is long enough that teams should copy a deliberate configuration into workspace dependencies instead of enabling broad defaults.
Compile-time checks are useful and demanding
The query! family is SQLx's defining feature. During compilation, a macro sends the SQL to a development database. That database checks the syntax and reports parameter and result metadata, allowing Rust to verify bind values and generate a typed result. Extensions and vendor-specific SQL still work because the database performs the analysis.
The cost is environmental. DATABASE_URL must point to the same kind of database and the same schema that production code expects. A developer changing a query needs that database available during compilation. CI needs it too, unless the project uses offline mode. The SQLx CLI can save query metadata into the repository so later builds can check the macro expansion without a live server. That file set then becomes another generated artifact that must stay in sync with SQL and migrations.
For teams already running database-backed integration tests, this is a fair trade. The compiler catches a misspelled column or wrong parameter type before deployment. Libraries, cross-compilation jobs, and tightly sandboxed builds may find the live-schema dependency intrusive. The README also warns that verified macros add meaningful compile work and suggests optimizing the macro crate in development profiles.
What happened when we ran it
We cloned commit 1d15be8 into a fresh Debian container with three CPUs, 12 GB of RAM, Rust tooling, and no secrets. Installation succeeded in 38 seconds with 114 packages installed. The build succeeded in 40 seconds. Tests ran for 78 seconds, then exited with code 101: 8 passed and 16 failed out of 24.
The visible tail comes from the any integration target. It reports zero passed and eight failed in that target, including tests for connecting, pinging, querying by string arguments, pooling, column lookup, and continuing a stream after a decoding error. Cargo's final line says to rerun with --test any. The excerpt contains no connection error or panic message, so it does not prove why those cases failed.
SQLx's own CI file shows the missing context around a full contributor run. Separate jobs start supported database versions, set DATABASE_URL, configure TLS cases, and isolate tests that need special handling. Our plain command did not reproduce that matrix. The failed run is still important: cloning and typing cargo test in a clean Rust container does not produce a green suite. Contributor documentation should point more directly to the required local services.
A broad toolkit, with clear edges
Connection pooling is built in, and results can stream as they are decoded rather than collecting every row first. The higher-level query API prepares and caches statements per connection. PostgreSQL users also get asynchronous LISTEN and NOTIFY, while nested transactions use savepoints. These are the facilities most application services would otherwise assemble from adjacent crates.
SQLx deliberately avoids an ORM's relationship model, change tracking, and generated object graph. That restraint is a strength for teams with complex SQL or database extensions. It is frustrating for developers who expect entity definitions to drive migrations and queries. SeaORM and Diesel are better evaluations for that style.
Microsoft SQL Server users have a harder stop. The README says MSSQL support existed before version 0.7 and was removed pending a full driver rewrite connected to the SQLx Pro initiative. An old code example or feature list can therefore be misleading. New projects should choose a currently maintained SQL Server driver instead of building around an unspecified future return.
SQLite carries another boundary. Its driver calls the C SQLite API and therefore uses unsafe code in a contained module, while the PostgreSQL and MySQL drivers forbid unsafe code. Users can choose bundled SQLite or link a system copy. The unbundled route can fail when the host SQLite is too old and can make compilation heavier because it uses bindgen.
Health and the decision
The repository was pushed on August 20, 2026, and issues were still receiving updates on August 24. Its 770 open items include both issues and pull requests, which is a large maintenance queue rather than 770 confirmed defects. Current discussions cover connection retry behavior, migration reverts with PostgreSQL search paths, CLI error messages, SQLite dependency bounds, and new preparation workflows.
GitHub's latest-release endpoint returns no release object for the current repository, although the tag list includes v0.9.0 and the README tells users to depend on the 0.9 line. That packaging wrinkle does not look like abandonment because code and issue activity are current. It does mean users should follow crates.io and Git tags instead of assuming GitHub Releases is the canonical channel.
Choose SQLx when handwritten SQL is a team skill and database-backed CI is already normal. Pin the feature set, decide early between live and offline query checking, and reproduce the upstream service matrix for changes that touch drivers. The library pays back that effort with direct SQL, strong Rust types, and an async API that covers most of a production service's database layer.