Query Engines & Federated SQL

Federated query engines run SQL across multiple data sources — warehouses, object storage, OLTP databases, SaaS APIs — without moving the data. Pairs with Lakehouse Table Formats (the on-disk side) and Data Warehouses (where you'd put materialized results). For ETL into a single warehouse instead of federating, see ETL / ELT & Ingestion.

Distributed JVM engines

• ★ Trino — the dominant OSS federated SQL engine; Apache 2.0. Connectors to almost every warehouse, file format, and OLTP DB. Starburst is the commercial sponsor / hosted version.
• Presto — the original; Apache 2.0; PrestoDB at Meta; superseded by Trino in most new deployments.
• Apache Spark SQL — runs on Spark; Apache 2.0; broader than just SQL but very capable as a query engine.
• Apache Drill — Apache 2.0; older; less active.
• Apache Impala — Apache 2.0; HDFS-flavored.

Embedded / single-node engines

• ★ DuckDB — see Data Warehouses and Data Exploration & EDA; MIT. Reads Parquet / CSV / JSON from S3 / HTTP / Postgres / MySQL via extensions. The single best "SQL on anything in one binary" tool in 2026.
• ★ Apache DataFusion — Rust query engine; Apache 2.0; the substrate under InfluxDB v3, Ballista, and many newer engines. Library, not a server.
• chDB — embedded ClickHouse; Apache 2.0; stronger than DuckDB on some analytical workloads.
• Polars — primarily a DataFrame engine but supports lazy SQL; see Data Exploration & EDA.

Postgres-flavored federation

• postgres_fdw + other Postgres FDWs (mysql_fdw, tds_fdw, parquet_fdw, clickhouse_fdw) — federate from inside Postgres. Useful at small scale; not a substitute for Trino.
• Multicorn — Python FDW framework; write your own foreign data wrapper.
• Steampipe — SQL APIs over SaaS / cloud-provider APIs (AWS, GCP, Azure, GitHub, Stripe, …); AGPLv3. Useful for "SQL my cloud bill" / "SQL my GitHub org."
• pg_duckdb — embed DuckDB inside Postgres for analytics queries on the same instance; MIT.
• Spice.ai OSS — embeddable SQL data fabric over Postgres / Iceberg / Snowflake / S3; Apache 2.0; pairs with their Cloud.

Lakehouse-native engines

• StarRocks, Apache Doris, ClickHouse, Dremio — see Data Warehouses; all read Iceberg / Delta natively in 2026.
• Snowflake, BigQuery, Athena, Redshift Spectrum — paid managed engines that read Iceberg.

Hosted federated query

• Starburst Galaxy — managed Trino; small free trial.
• Spice.ai Cloud — hosted Spice.ai; small free tier.
• MotherDuck — DuckDB-as-a-service; small free tier; "your laptop joins the cloud."
• Tinybird — ClickHouse-flavored; managed; small free tier.

Patterns to adopt

• Push down predicates and projections. Engines that don't push filters to the source pull whole tables; Trino, DuckDB, DataFusion do this well — verify with EXPLAIN.
• Materialize hot federated joins. Federation is great for ad-hoc; for nightly dashboards, ETL into one warehouse.
• Cache the planning, not just the data. Trino's metadata caching saves a surprising amount of latency.
• Keep secrets at the engine, not the query. Most engines support per-catalog credential mounts; never inline credentials in SQL.
• Use Iceberg as the lingua franca. A single Iceberg table is queryable by every engine listed here — federation becomes trivial.
• Don't federate where ELT would be cheaper. Joining a SaaS API to a warehouse over the wire on every query is usually worse than nightly ELT.

Pick this if…

• Default federated SQL at scale: Trino.
• Default single-node SQL on files / S3: DuckDB.
• Build a query engine into your product: Apache DataFusion.
• SQL over your AWS / GitHub / Stripe APIs: Steampipe.
• Postgres + analytical engines on one instance: pg_duckdb.
• No-ops federated query, hosted: Starburst Galaxy or Spice.ai Cloud.
• Lakehouse-only: any Iceberg-compatible engine; StarRocks / Trino / DuckDB are the most common picks.