Flight SQL Driver#
The Flight SQL Driver provides access to any database implementing a Arrow Flight SQL compatible endpoint.
The Flight SQL driver is shipped as a standalone library.
go get github.com/apache/arrow-adbc/go
pip install adbc_driver_sqlite
To connect to a database, supply the “uri” parameter when constructing
#include "adbc.h" // Ignoring error handling struct AdbcDatabase database; AdbcDatabaseNew(&database, nullptr); AdbcDatabaseSetOption(&database, "driver", "adbc_driver_flightsql", nullptr); AdbcDatabaseSetOption(&database, "uri", "grpc://localhost:8080", nullptr); AdbcDatabaseInit(&database, nullptr);
import adbc_driver_flightsql.dbapi with adbc_driver_flightsql.dbapi.connect("grpc://localhost:8080") as conn: pass
The Flight SQL driver generally supports features defined in the ADBC API specification 1.0.0, as well as some additional, custom options.
The driver does no authentication by default. The driver implements a few optional authentication schemes:
Mutual TLS (mTLS): see “Client Options” below.
An HTTP-style scheme mimicking the Arrow Flight SQL JDBC driver.
Set the options
AdbcDatabase. Alternatively, set the option
adbc.flight.sql.authorization_headerfor full control.
The client provides credentials sending an
authorizationfrom client to server. The server then responds with an
authorizationheader on the first request. The value of this header will then be sent back as the
authorizationheader on all future requests.
Flight SQL does not have a dedicated API for bulk ingestion of Arrow data into a given table. The driver does not currently implement bulk ingestion as a result.
The options used for creating the Flight RPC client can be customized. These options map 1:1 with the options in FlightClientOptions:
The certificate chain to use for mTLS.
The private key to use for mTLS.
Override the hostname used to verify the server’s TLS certificate.
Disable verification of the server’s TLS certificate. Value should be
Override the root certificates used to validate the server’s TLS certificate.
Whether connections should wait until connections are established, or connect lazily when used. The latter is gRPC’s default behavior, but the driver defaults to eager connection to surface errors earlier. Value should be
The maximum message size to accept from the server. The driver defaults to 16 MiB since Flight services tend to return larger reponse payloads. Should be a positive integer number of bytes.
Custom Call Headers#
Add the header
<HEADER NAME>to outgoing requests with the given value.
Header names must be in all lowercase.
Distributed Result Sets#
The driver will fetch all partitions (FlightEndpoints) returned by the server, in an unspecified order (note that Flight SQL itself does not define an ordering on these partitions). If an endpoint has no locations, the data will be fetched using the original server connection. Else, the driver will try each location given, in order, until a request succeeds. If the connection or request fails, it will try the next location.
The driver does not currently cache or pool these secondary connections. It also does not retry connections or requests.
All partitions are fetched in parallel. A limited number of batches are queued per partition. Data is returned to the client in the order of the partitions.
The queue size can be changed by setting an option on the
The number of batches to queue per partition. Defaults to 5.
The driver currently will not populate column constraint info (foreign
keys, primary keys, etc.) in
Also, catalog filters are evaluated as simple string matches, not
Partitioned Result Sets#
The Flight SQL driver supports ADBC’s partitioned result sets. When requested, each partition of a result set contains a serialized FlightInfo, containing one of the FlightEndpoints of the original response. Clients who may wish to introspect the partition can do so by deserializing the contained FlightInfo from the ADBC partitions. (For example, a client that wishes to distribute work across multiple workers or machines may want to try to take advantage of locality information that ADBC does not have.)
By default, timeouts are not used for RPC calls. They can be set via
special options on
AdbcConnection. In general, it is
best practice to set timeouts to avoid unexpectedly getting stuck.
The options are as follows:
A timeout (in floating-point seconds) for any API calls that fetch data. This corresponds to Flight
For example, this controls the timeout of the underlying Flight calls that fetch more data as a result set is consumed.
A timeout (in floating-point seconds) for any API calls that execute a query. This corresponds to Flight
For example, this controls the timeout of the underlying Flight calls that implement
A timeout (in floating-point seconds) for any API calls that upload data or perform other updates.
For example, this controls the timeout of the underlying Flight calls that implement bulk ingestion, or transaction support.
The driver supports transactions. It will first check the server’s
SqlInfo to determine whether this is supported. Otherwise,
transaction-related ADBC APIs will return