databend-driver

databend-driver is the official Rust client for Databend, the cloud-native data warehouse. It offers a single, unified SQL interface that can talk to Databend over the REST API or over Apache Arrow FlightSQL, so the same code works against Databend Cloud and self-hosted deployments.

Connections are configured through a DSN string; from there you get an async API to execute DDL and DML, run queries, stream result sets, and load data. Result rows can be destructured directly into native Rust types, and the driver supports a builder-style query API for parameter binding. It is part of the bendsql workspace, which also produces the bendsql CLI and language bindings built on top of the same core.

What You Get

• A Client/Connection API configured from a Databend DSN string
• Unified access over both the REST API and Apache Arrow FlightSQL transports
• Async execution of DDL/DML plus single-row, streaming, and builder-based queries
• Result rows that destructure directly into native Rust tuples and types

Common Use Cases

• Querying and loading data into Databend from a Rust application or service
• Switching between REST and FlightSQL transports without changing query code
• Mapping Databend query results into strongly-typed Rust structs and tuples

Under The Hood

Architecture — databend-driver sits at the top of the bendsql Cargo workspace’s layered crate stack: it builds on databend-driver-core and databend-client, which implement the actual REST and FlightSQL transports. A Client created from a DSN yields Connection handles that expose exec, query_row, query, and streaming interfaces; the FlightSQL path is feature-gated and pulls in arrow-flight, arrow-schema, and tonic. The same core powers the sibling cli (bendsql) and bindings crates in the repo.

Tech Stack — Rust across a workspace, async on Tokio, with TLS selectable between rustls (default) and native-tls via Cargo features. FlightSQL support layers Apache Arrow crates and gRPC (tonic) on top of the base REST client.

Code Quality — The workspace is actively maintained with consistent releases and roughly two dozen source files carrying unit and tokio::test async tests, plus an integration tests/ directory and enforced formatting/lint config (rustfmt, taplo, deny).

API Design — The public API reads naturally for SQL work: connect from a DSN, exec statements, query_row/query for reads, and try_into to map rows into Rust tuples. A builder-pattern query API adds parameter binding without ceremony, and transport selection is a configuration concern rather than an API change.