Abstract
Arrow Flight SQL offers a wire protocol for SQL query execution built on top of Apache Arrow Flight, using gRPC as the transport layer and returning results in Arrow record batch format. The protocol eliminates the serialization round-trip that makes JDBC and ODBC expensive at scale: query results flow directly as columnar Arrow buffers from server to client without intermediate row conversion. By early 2026, DuckDB, Dremio, Starburst, and ClickHouse all ship Flight SQL endpoints in production-ready or near-production form, and the broader adoption pattern is clarifying. This post examines where Flight SQL delivers measurable throughput gains, where it does not, and what the implementation gaps still look like from a client integration standpoint.
Where the Protocol Wins
The performance case for Flight SQL is clearest when queries return large result sets to analytical clients - dashboards ingesting millions of rows, Python notebooks pulling a full dataset for local processing, or ML feature pipelines reading training data from a query engine. JDBC and ODBC pay serialization cost proportional to result size: rows are converted from the engine’s internal columnar format to a row-oriented wire format, sent, and then converted back to columnar by the client library. With Flight SQL, the server streams Arrow record batches that a Python client receives directly into a PyArrow table with zero copy. DuckDB’s internal benchmarks from 2025 show 3-5x throughput improvement over JDBC for queries returning more than 100K rows; the crossover point where Flight SQL’s gRPC overhead breaks even with JDBC’s simplicity is typically around 10K rows.
Parallel Stream Support
Flight SQL defines a GetFlightInfo + DoGet flow that allows the server to partition a result into multiple streams, each retrievable independently. A client that issues a query can receive a list of endpoints, each representing a partition of the result, and fetch them in parallel across multiple connections or across multiple client machines. Dremio’s Flight SQL implementation exposes this for queries where it can partition by file or by executor node. For large joins and aggregations that produce multi-billion-row results, parallel stream retrieval is the capability that makes Flight SQL qualitatively different from a faster JDBC - it enables distributed data transfer rather than a single-stream bottleneck.
Client Ecosystem Maturity
The practical constraint on Flight SQL adoption is client library maturity. ADBC (Arrow Database Connectivity), the Arrow project’s database connectivity standard that Flight SQL implements, has production-ready drivers for Python and Go. The Java ADBC driver is stable. R bindings exist but are less polished. JDBC shim layers over Flight SQL - which allow legacy JDBC tooling to use the protocol without code changes - are available from Dremio and as an open-source project from the Arrow community, but they negate most of the performance advantage by reintroducing row serialization at the shim boundary. Tools like Tableau and Power BI, which remain JDBC/ODBC-first, require the shim or a native connector development effort that most server-side implementors have not yet prioritized.
Transaction and Catalog Surface
Flight SQL’s SQL transaction support covers begin, savepoint, commit, and rollback, but the protocol’s catalog introspection calls - GetCatalogs, GetSchemas, GetTables - are schema-fixed and less expressive than what modern catalog APIs like the Iceberg REST catalog or Unity Catalog expose. Clients that need to discover table metadata, read partition specs, or inspect column statistics beyond the basic SQL information schema must make out-of-band calls to a separate catalog API. This is not a fundamental limitation of the protocol, but it means Flight SQL alone is not a drop-in replacement for the full catalog-plus-execution surface that a modern analytical platform exposes.