Arrow Flight SQL gRPC server for the Rhei HTAP engine.

This crate exposes the OLAP backend (DataFusion or DuckDB) over the Arrow Flight SQL protocol, letting clients such as adbc_driver_flightsql (Python), DBeaver, or any standard Arrow Flight SQL driver run analytical queries via gRPC.

Architecture

The crate is built on arrow-flight 58 and tonic 0.14. The core service is [RheiFlightSqlService], which implements FlightSqlService and delegates all query execution to [rhei_olap::OlapBackend].

Deferred-execution pattern

get_flight_info_* encodes the SQL string into an opaque ticket and returns a FlightInfo immediately — no query planning occurs yet. When the client calls do_get_* with that ticket, the service decodes the SQL, calls [rhei_core::OlapEngine::query_stream], and streams Arrow IPC record batches back over the gRPC connection.

Tickets are cheap opaque byte handles; deferring query planning to do_get keeps get_flight_info latency negligible and avoids holding engine resources while the client is not yet ready to consume data.

Compression

Arrow IPC record batches are compressed before transmission. [CompressionType::Zstd] is the default — it offers the best size/CPU tradeoff for typical columnar workloads. [CompressionType::Lz4] is available for CPU-constrained clients that need faster decompression. [CompressionType::None] disables compression entirely, which is useful on loopback or high-bandwidth LAN links.

Read-only constraint

All write operations (do_put_*) return tonic::Status::unimplemented. Rhei's OLAP layer carries no DML semantics — INSERT / UPDATE / DELETE go through the OLTP engine (Rusqlite) on a separate path.

Quick start

use std::net::SocketAddr;
use rhei_flight::serve_flight_sql;
# async fn example(olap: rhei_olap::OlapBackend) -> Result<(), Box<dyn std::error::Error>> {
let addr: SocketAddr = "0.0.0.0:50051".parse()?;
serve_flight_sql(olap, addr).await?;
# Ok(()) }