Select from Tables

Query remote data using standard SELECT statements with Airport - supports streaming, predicate pushdown, and Parquet file locations.

The Airport extension enables DuckDB to query remote data using standard SELECT statements. Through Arrow Flight integration, data can be either streamed directly or accessed via returned locations (such as URLs to Parquet files). Arrow Flight servers may optionally filter results server-side using query predicates before returning data.

Example

You can query Airport-managed tables just like any other DuckDB table:

-- Attach an Airport database
ATTACH 'example' (TYPE AIRPORT, location 'grpc://localhost:50312/');

-- Assume that there is a `main` schema
-- already in the `example` database
CREATE TABLE example.main.employees (
  name varchar,
  id integer
);

SELECT * FROM example.main.employees;

-- Queries that specify a point in time
-- or version of the table are supported, if
-- the Arrow flight server supports it.
SELECT * FROM example.main.employees AT (TIMESTAMP => TIMESTAMP '2020-01-01');
SELECT * FROM example.main.employees AT (VERSION => 42);

Airport tables can be joined with other tables or combined with multiple Airport sources in a single query. DuckDB fetches data in parallel, limited only by the available thread pool size. Each reference to a table results in an independent request to the Arrow Flight server.

Arrow Flight Server Implementation Notes

DuckDB Catalog Integration

To learn how to register an Arrow Flight data as a DuckDB table, refer to Server Catalog Integration.

Time Travel / Point in Time Lookup

When a query includes time travel or point-in-time semantics, the Airport extension issues a flight_info RPC. This retrieves the FlightInfo structure representing the table as it existed at that specific moment in time. This ensures that queries reflect the correct schema, even if the table has evolved over time.

Endpoint and Location Lookup

To retrieve data from a flight, the Airport extension uses a DoAction RPC with the endpoints action instead of the standard GetFlightInfo RPC.

Reasons for using DoAction:

  1. Schema already known — The table schema is cached from catalog discovery, eliminating redundant schema transfers.
  2. Predicate pushdown — Filter predicates can be serialized and sent to the server, enabling server-side filtering. The standard GetFlightInfo RPC only accepts a FlightDescriptor without additional context.