SQL Server remains one of the most widely deployed engines in the enterprise. Integrating it into a desktop client written in Rust raises three concrete questions: which client to use, how to manage an asynchronous connection pool, and how to paginate while respecting the dialect. QoreDB decided in favor of Tiberius, a native Rust TDS client, paired with the bb8 pool. This article details these choices and what they imply.
All the code described here lives in src-tauri/crates/qore-drivers/src/drivers/sqlserver.rs and its companion SQL compilation module qore-query/src/compiler/mssql.rs. Everything is open and inspectable.
Tiberius, a pure-Rust TDS client
Tiberius directly implements the TDS (Tabular Data Stream) protocol used by SQL Server. No ODBC driver, no binding to a system C library, no native dependency to install. The client connects over TCP via tokio, and a compat layer (tokio_util::compat) bridges tokio's async traits and those used by tiberius.
Keeping the entire pipeline in Rust simplifies cross-platform distribution. The Tauri binary depends neither on an ODBC Driver Manager on Linux nor on the SQL Server Native Client on Windows. The cost is that some advanced SQL Server features (Always Encrypted, certain auditing options) are not exposed by Tiberius. For a desktop data-inspection client, the trade-off is coherent.
Three authentication modes, including Windows conditions
QoreDB exposes three modes via the MssqlAuthMode enum: SQL password, Windows NTLM, and Windows Integrated. The SQL password mode works everywhere. The NTLM mode requires a DOMAIN\user or user@DOMAIN format and is only compiled on Windows. The Integrated mode relies on the current Windows session. All of this is decided at compile time via #[cfg(windows)], which avoids offering an option in the UI that could not succeed on the current platform.
TLS encryption follows the form's ssl option: EncryptionLevel::Required if the box is checked, EncryptionLevel::NotSupported otherwise. trust_cert is enabled by default to make usage with internal certificates easier, in line with the typical use of an administration client.
Why bb8 for the connection pool
Tiberius does not provide a built-in pool, unlike SQLx for PostgreSQL or MySQL. The bb8 crate is the async equivalent of r2d2, and bb8_tiberius exposes an already-wired ConnectionManager. The SQL Server session therefore exposes a Pool<ConnectionManager>, with a default maximum size of 10 and an acquisition timeout of 15 seconds, both configurable from the connection config.
The pattern stays aligned with that of the PostgreSQL driver: a shared pool for ordinary queries, and a dedicated connection for transactions, stored behind a Mutex. This choice cleanly isolates explicit transactions, prevents them from relying on a connection reused by other queries in the pool, and keeps the rollback-or-commit logic predictable.
Pagination with native OFFSET/FETCH
SQL Server does not have a LIMIT clause like PostgreSQL or MySQL. The official syntax for server-side pagination, since SQL Server 2012, is OFFSET n ROWS FETCH NEXT m ROWS ONLY, inherited from the SQL:2008 standard. QoreDB uses it as is, with no attempt to rewrite it as TOP or ROW_NUMBER(). The project's SQL compiler exposes a DialectOps trait where the mssql implementation returns LimitStyle::OffsetFetch, and identifier quoting is done with square brackets via write_quoted_mssql.
This pagination is used both for listing tables via INFORMATION_SCHEMA and for the paginated reading of a business table. A separate COUNT query provides the total, which makes it possible to display an exact counter in the data grid without touching the main fetch mechanism. This approach suits the typical volumes of an administration client; for very large collections where the COUNT becomes expensive, infinite scroll on the UI side avoids paying that price systematically.
Cancellation via KILL spid
QoreDB tracks each active query in a QueryId → SPID map. When the user clicks Stop, the cancel method retrieves the relevant SPID and runs KILL <spid> on a fresh connection from the pool. This is the official mechanism on the SQL Server side.
Each engine has its own verb: pg_cancel_backend on PostgreSQL, KILL QUERY on MySQL, best effort on MongoDB via killOp. QoreDB does not try to unify these commands behind a common abstraction; each driver exposes the cancel method with the right command in the logic of the underlying engine. The frontend calls the same Tauri API, but what happens underneath stays faithful to the native protocol.
In real-world use
On the user side, the configuration comes down to host, port (1433 by default), database, authentication mode, and TLS option. The connection test uses a raw connection (outside the pool) to give immediate feedback without reserving resources. Once the connection is open, navigation by schema (the SQL Server schema concept, not the database) is handled natively, identifier quoting with square brackets is applied everywhere in the data grid, and KILL is available behind the cancel button in the query panel.
On macOS and Linux, the Windows NTLM mode is not compiled: tiberius does not provide the NTLM implementation outside Windows. SQL authentication remains the relevant mode in these contexts, which matches the majority of SQL Server installations exposed to developers.
Conclusion
Tiberius plus bb8 keeps the entire SQL Server driver in the same Rust toolchain as QoreDB's other drivers. The OFFSET/FETCH pagination, the square-bracket quoting, the KILL spid, and the three auth modes respect exactly the engine's native grammar. This is the technical transparency logic that structures QoreDB: you talk to SQL Server the way SQL Server expects to be talked to, with no emulation layer that would mask what it actually does.
Stay updated on new releases
Subscribe to get product releases, new drivers notifications, and technical tutorials.