# The ScyllaDB Rust driver is a native CQL client with a 1.x promise

> scylla-rust-driver is a pure Rust, fully async CQL driver for ScyllaDB that also speaks to Apache Cassandra, with token-aware and shard-aware routing, zero-copy deserialization and derive macros. It is production ready, but the project reserves the right to ship a 2.0, and its MSRV policy is one of the more disciplined in the ecosystem.

**scylladb/scylla-rust-driver** — Async CQL driver for Rust, optimized for ScyllaDB!

- Repository: https://github.com/scylladb/scylla-rust-driver
- Stars: 691 · Forks: 168
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/scylladb-scylla-rust-driver

## A CQL client written in Rust, not wrapped around C++

The ScyllaDB Rust driver is a client-side driver for ScyllaDB written in pure Rust with a fully async API using Tokio. Two details in that sentence matter for adoption. Pure Rust means no C++ core to compile, no FFI boundary to cross, and no separate service to deploy, which is the usual answer when a Java or C++ Cassandra driver sits in a Rust stack. Fully async means the driver participates in the same Tokio runtime as the rest of your service, so a database call is awaited in the same task as an HTTP request rather than occupying a blocking thread pool. The driver is optimized for ScyllaDB but is also compatible with Apache Cassandra, which means the same code can move between the two databases. The reference documentation it points to is the CQL binary protocol specification version 4, so the wire format is a published contract rather than an implementation detail, and the project lists two alternative drivers for the Apache Cassandra case, cdrs-tokio, an Apache Cassandra driver written in pure Rust, and cassandra-rs, Rust wrappers for the DataStax C++ driver.

## Routing that knows about shards, tablets and tokens

The feature list is where this driver separates itself from a generic Cassandra client, and three entries are ScyllaDB specific. Token-aware routing sends a query to the node that owns the token range, so a coordinator forwards the minimum. Shard-aware routing is ScyllaDB specific and pushes that further, sending a request to the shard that actually holds the data. Tablet-aware routing is also listed as specific to ScyllaDB and covers the newer tablet-based sharding model. The difference between token-aware and shard-aware matters in practice, because with shard awareness a driver can address a single shard on a node rather than a token range that may straddle several. Alongside that there is a CachingSession that transparently prepares statements, so a caller does not have to think about prepared versus unprepared on the hot path, while the driver still exposes prepared, unprepared and batch statements directly. Query paging is available both transparently and manually, and the execution profiles and configurable policies cover load balancing, retry, speculative execution, timestamp generation, address translation and host filtering.

## Typed rows, zero-copy deserialization and derive macros

The serialization story is the part Rust developers will care about most. The driver supports type-safe serialization and deserialization, zero-copy deserialization, and derive macros for user struct serialization and deserialization. The practical effect is that a row can be read straight into a tuple or a struct you define, and the row values are not copied out of the driver buffer to do it. The README example shows the shape of that.

```rust
let query_pager = session.query_iter("SELECT a, b, c FROM ks.t", &[]).await?;
let mut stream = query_pager.rows_stream::<(i32, i32, String)>()?;
while let Some((a, b, c)) = stream.try_next().await? {
    println!("a, b, c: {}, {}, {}", a, b, c);
}
```

The type parameters on rows_stream are the row type, and the stream is consumed with try_next from the futures TryStreamExt trait, so errors surface as Results rather than panics. The examples directory makes the same point more thoroughly, with files for custom serialization, custom deserialization, a comparison of token routing, schema agreement, select paging, speculative execution, execution profiles, query history, metrics, authentication, batching, bound statements, parallel execution, client routes, logging via log and via tracing, and a cqlsh replacement written in Rust. The custom serialization and deserialization examples are the ones to read if your data does not fit a derive.

## Running the example against a local node

The example program is in the repository, and the README gives the command for running it against a server you already have.

```sh
SCYLLA_URI="127.0.0.1:9042" cargo run --example basic
```

The session itself is built from a known node, and the session builder is the entry point for connection configuration.

```rust
let uri = "127.0.0.1:9042";

let session: Session = SessionBuilder::new().known_node(uri).build().await?;
```

So the shape of a client is: build a session from at least one known node, then run queries against it. The rest of the configuration, the load balancing policy, the retry policy, the TLS setup, the compression algorithm, the authentication method, the execution profiles, all of it is documented in the documentation book rather than in the README, and the README points at that book and at the Rust and ScyllaDB lesson on Scylla University as the two places to start. The driver is published on crates.io as scylla, with API docs on docs.rs, and the minimum supported Rust version is advertised on the crate badge as well as stated in the version support section.

## The features you enable are the features you get

The driver has several optional features that can be enabled or disabled in Cargo.toml, with the list in the scylla crate manifest on docs.rs. That is worth pausing on, because TLS and compression are the two items on the feature list most teams consider mandatory, and a driver that makes them optional is a driver whose default build may not do what a production deployment needs. The Makefile in the repository shows how carefully the project treats the feature matrix in CI. There is a check-without-features target that builds only the main target, because passing --all-targets turns on some features anyway through feature unification, and there are separate checks for building without the unstable cfg, without unstable and features together, and with all features. The unstable surface is gated behind a RUSTFLAGS cfg of scylla_unstable, which is exported by the Makefile, so experimental behaviour is opt-in at build time rather than at runtime. Clippy runs with -Dwarnings both with and without all features, and cargo deny checks the dependency licences. The result is a crate where the feature matrix is a tested artefact rather than a documentation promise.

## The 1.x promise and the 2.0 that is coming

The version support section is unusually explicit and is the part of the README most adopters should read twice. The driver is considered production ready, which is why its version is not 0.x, and the project acknowledges that the API will need breaking changes, which means staying on 1.x forever is explicitly not the goal. The guarantee offered is about frequency rather than permanence. New major versions will not be released very often, and in the case of 2.0 it will not be released earlier than nine months after 1.0, with the duration possibly increased for later major versions. After a new major version ships, the previous major version still receives bugfixes for some time, though the exact period is not yet determined, and new features are developed only for the latest major version. The minimum supported Rust version is 1.89.0, and the policy around it is spelled out with the same care. MSRV changes can happen in major and minor releases but not in patch releases, and it will not be bumped to a Rust version released less than six months earlier. So a patch upgrade of the driver cannot raise your compiler floor, which is what makes a lockfile update safe.

## What the driver is not, and where the other options sit

Three things to weigh before choosing it. The first is that the routing and policy features that make this driver good for ScyllaDB, shard-aware and tablet-aware routing, are the same features that make it less obviously right for plain Apache Cassandra, where the sharding model is different and token-aware routing is the ceiling. The second is the Tokio commitment. A fully async API is right for a Rust service that is already async, and awkward for a codebase that is mixed, because you cannot call into it from a blocking thread without a runtime bridge. The third is that the crate is a workspace of many crates, scylla, scylla-cql, scylla-cql-core, scylla-macros, scylla-proxy, scylla-ccm-bridge, plus benchmarks, examples and utility crates, and the test infrastructure is a Scylla cluster in Docker Compose driven through the bridge, so the testing story is a real integration story rather than a mock. The maintenance record is active, with 1.7.0 in June 2026, 1.8.0 in August and 1.9.0 in September, and the last push on 2026-10-19. The licence is dual, Apache 2.0 or MIT at your option, which is one of the more permissive setups you can get. And the project is candid about what it does not promise, which is that the API will need breaking changes.

## Conclusion

Adopt scylla-rust-driver if you are running ScyllaDB or Apache Cassandra from a Rust service and want a native client with async I/O, typed rows and Scylla specific routing rather than a Java driver behind a sidecar. Skip it if your team cannot accept a 1.89 minimum Rust version, or if the API churn implied by a planned 2.0 would be a problem, because the project states plainly that staying on 1.x forever is not the goal. Before you pin a version, read the version support section, since a 2.0 will not arrive earlier than nine months after 1.0, and check whether the features you need, such as TLS or compression, sit behind a Cargo feature flag you have to enable explicitly.

## FAQ

### What is the scylla-rust-driver and what databases does it support?

It is a client-side driver for ScyllaDB written in pure Rust with a fully async API using Tokio. Although optimized for ScyllaDB, it is also compatible with Apache Cassandra, and it speaks CQL binary protocol version 4.

### How do I run the scylla-rust-driver example against a local node?

With a ScyllaDB server running, use SCYLLA_URI="127.0.0.1:9042" cargo run --example basic. The example program itself is in the examples directory of the repository, and the full set of examples is listed there.

### What is the minimum supported Rust version for the scylla-rust-driver?

The MSRV is 1.89.0. Changes to the MSRV can only happen in major and minor releases, not in patch releases, and it will not be bumped to a Rust version released less than six months ago.

### Will the scylla-rust-driver API break in a future 2.0?

Yes, that is expected. The project states it is not the goal to stay on 1.x forever, that new major versions will not be released very often, and that 2.0 will not come earlier than nine months after 1.0. The previous major version still receives bugfixes for some time after a new one ships.

## Sources

- [Issues](https://github.com/scylladb/scylla-rust-driver/issues)
- [License: Apache-2.0](https://github.com/scylladb/scylla-rust-driver/blob/main/LICENSE)
- [README](https://github.com/scylladb/scylla-rust-driver/blob/main/README.md)
- [Releases](https://github.com/scylladb/scylla-rust-driver/releases)
- [scylladb/scylla-rust-driver on GitHub](https://github.com/scylladb/scylla-rust-driver)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scylladb-scylla-rust-driver