Whether to federate queries across live sources or centralize data in a warehouse first comes down to latency tolerance, join size, and compliance requirements, not a blanket rule. Engines like Trino, Starburst, Dremio, Athena, and BigQuery Omni skip the ETL copy but push joins over the network. Warehouses trade real-time freshness for centralized compute and, at scale, often more predictable cost per query.
Quick Summary (TL;DR)
- Federation queries source data in place; centralization loads it into a warehouse first via ETL. The trade-off is freshness versus raw join performance on very large tables.
- For small to medium joins, engines like Trino and Starburst can be interactive. Very large or high-concurrency joins generally run faster in a centralized MPP warehouse.
- Serverless federation (Athena, BigQuery Omni) bills per TB scanned, typically $5/TB. Self-managed engines (Trino, Starburst, Dremio) carry cluster and licensing costs instead.
- No independent, vendor-neutral TCO study compares federation to warehousing directly. The closest data point is a GigaOm-sourced Starburst benchmark showing comparable TPC-DS cost to Snowflake.
- BigQuery Omni recommends keeping cross-cloud joins under roughly 60 GB per subquery, and it only reads S3 or Azure Blob object storage, not live databases.
- Denodo and Starburst/Trino connect to MongoDB, but they translate documents into flattened SQL rows rather than querying the native nested structure.
- Outside of Knowi, none of the anchor federation engines bundle a BI or visualization layer. Trino, Starburst, Dremio, Athena, and Denodo all require a separate dashboarding tool.
The 8 Factors That Decide Federate vs Centralize
Most articles frame this as ideology, no-ETL versus traditional pipelines, when it is an engineering trade-off with measurable variables. Knowi’s own posts already cover the general case for skipping ETL with no-ETL business intelligence and joining SQL and NoSQL data without moving it. This section covers what determines which named engine fits a specific workload.
Latency and Query Complexity
Real-time dashboards that need sub-second responses generally favor data locality, since centralized compute means joins do not wait on network round-trips. Federated queries fetch from remote sources every time, so latency scales with data size and distance. Small or medium queries can stay interactive under federation, but very large joins or high-concurrency workloads more often win on raw speed in a centralized MPP warehouse like Snowflake, BigQuery, or Redshift.
Cost Model: Per-Query vs Cluster
Serverless engines like Athena and BigQuery Omni charge by data scanned, typically $5 per TB. Self-hosted engines like Trino, Starburst, and Dremio carry fixed cluster and license costs regardless of query volume, so a warehouse’s fixed-cost amortization can end up cheaper per query on large, repeated workloads. Federation avoids duplicating storage since there is no second data copy, but can add cost elsewhere: egress, Lambda invocations for Athena connectors, or engineering time spent tuning connectors.
Data Freshness, Governance, and Source Load
Federated queries read live source data, suiting real-time analytics, while warehouses introduce lag through batch ETL measured in minutes to hours. When data residency rules require data to stay in its original location, federation is often mandated: BigQuery Omni and Athena Federated Query both allow cross-cloud reads without copying data out. Federated queries also put read load directly on production databases, which can hurt OLTP performance; centralizing isolates that load, at the cost of the upfront ETL run.
Engineering Effort and Concurrency
Open-source engines like Trino and Dremio need in-house expertise to cluster, scale, and tune, while warehouses shift that burden into ETL pipeline maintenance: schema drift, job failures, and model changes. Serverless warehouses can elastically absorb large concurrent workloads, while a self-managed Trino cluster has a finite concurrency ceiling per node pool, and Athena defaults to roughly 20 simultaneous queries per account before a quota increase.
Federation Engine by Engine: Cost, Latency, and Real Limits
Figures below come from published pricing pages and vendor benchmark reports. Where no public figure exists, that is stated rather than estimated.
Trino (Open Source)
Trino is a distributed MPP engine: a coordinator plans the query, and workers connect to each source through plug-in connectors, streaming and joining data in memory instead of copying it first. It is free and open source, so cost is infrastructure plus operations; one Concurrency Labs case study put a 21-node Trino cluster at roughly $18,000 per month on AWS. In a TPC-DS test, Starburst (Trino’s commercial distribution) averaged 16 seconds per query versus 44 seconds for unmodified Presto on EMR, which also hit memory issues Starburst avoided. Trino connects to 40-plus source types, including MySQL, Postgres, Snowflake, BigQuery, MongoDB, and Hive/Parquet on S3.
Starburst (Enterprise Trino)
Starburst adds enterprise features to Trino’s core engine: fault-tolerant execution and a Cache Service that materializes hot data. Starburst Galaxy bills by credit, $0.50 to $1.00 each; the self-hosted Enterprise license ran roughly $6,328 per month for a 21-node cluster, on top of compute. A GigaOm-sourced report Starburst cites found cost and query times comparable to Snowflake on TPC-DS, and about 4x faster with 5x better cost-efficiency on complex JSON analytics specifically. Concurrency Labs found Starburst ran 2.5x faster than open Presto on EMR, at roughly $22,500 per month versus $18,200, a 60% higher license cost offset by faster completion.
Dremio
Dremio pairs a query engine with a virtualization layer on Apache Arrow. Its differentiator is Reflections, materialized aggregates stored as Parquet, so frequent sub-queries can approach warehouse speed even though the query still hits original sources. Pricing is subscription-based with no public per-node rate; without reflections configured it behaves like any network-limited federated engine, and one informal 2020 comparison found a 2-node Dremio and Athena performed similarly on 10 to 500 GB queries. It connects to S3, Redshift, Snowflake, Databricks, Postgres, MongoDB, and formats like Iceberg and Delta Lake directly.
Amazon Athena
Athena is a managed, serverless SQL service built on Presto that queries S3 data in place by default; Athena Federated Query extends it to other sources through Lambda-based connectors. Pricing is $5.00 per TB scanned across S3 and federated sources, plus standard Lambda charges. AWS provides managed connectors for roughly 12 sources as of 2026, including DynamoDB, RDS, Snowflake, and MongoDB, with more via the community SDK. There is no source-side join pushdown, so an unfiltered join can force a full table scan, and default concurrency is roughly 20 simultaneous queries per account.
BigQuery Omni
BigQuery Omni extends BigQuery’s control plane to AWS S3 and Azure Blob Storage: Google runs a data-plane cluster inside the customer’s region, so compute happens where the data lives. Pricing follows standard BigQuery rates with no separate cross-cloud fee. Omni currently only reads cloud object storage via BigLake tables, not live databases like RDS or Snowflake, and Google recommends keeping joins under roughly 60 GB per subquery. No independent benchmark for Omni performance is public.
Denodo
Denodo is a data virtualization platform built around a central Virtual DataPort server that splits incoming SQL into sub-queries, pushing down projections, filters, and joins where possible. Newer versions add an Embedded MPP engine, rebranded Lakehouse Accelerator, to parallelize queries over Parquet, Delta, and Iceberg data. Pricing is not public, quoted by deployment type, source count, user count, and CPU. No independent latency benchmark is public, and without the MPP accelerator, large joins funnel through a single engine. Denodo connects to most SQL databases, Hadoop/Hive, cloud warehouses, and MongoDB.
Knowi
Knowi combines query federation with built-in BI and AI, decomposing an incoming query into source-native sub-queries, for example a MongoDB aggregation and a PostgreSQL select run in parallel, then joining the results in its own engine. It documents native MongoDB querying, Elasticsearch analytics, and REST API sources across roughly 70 connectors, without flattening nested documents into rows first. Published pricing starts at $20,000 per year for 5 users, custom-priced above that, with no per-query fee. No independent or vendor TPC-DS/TPC-H benchmark for Knowi is public as of this writing, flagged as unverified rather than estimated; it trades some raw scale ceiling for native SQL-plus-NoSQL querying and a built-in dashboard layer.
How the Federation Engines Compare
| Engine | Cost model | Latency evidence | Where it breaks down |
|---|---|---|---|
| Trino | Open source; ~$18K/mo for a 21-node AWS cluster in one case study. | 16s/query avg (as Starburst) vs 44s for Presto on EMR. | No caching or BI layer; large joins can OOM workers. |
| Starburst | Galaxy credits ($0.50-$1.00 each) or Enterprise license (~$6,328/mo for 21 nodes) plus compute. | ~4.2s/query avg vs Snowflake’s 3.8s; ~4x faster on complex JSON. | License stacks on compute; credit billing can spike. |
| Dremio | Subscription, no public per-node pricing. | No independent benchmark; reflections approach warehouse speed on repeats. | Reflections need active tuning; unindexed sources behave like raw federation. |
| Amazon Athena | $5/TB scanned, plus standard Lambda charges. | No AWS benchmark; reports suggest near 8-node Presto performance. | No source-side join pushdown; unfiltered joins scan full tables. |
| BigQuery Omni | Standard BigQuery pricing ($5/TB); no cross-cloud fee. | No independent benchmark; recommends joins under ~60GB/subquery. | Reads only S3/Azure Blob, not live databases. |
| Denodo | Subscription, pricing not public. | No independent benchmark; single-engine execution slow on large joins without MPP. | Opaque pricing; NoSQL sources flattened into SQL rows. |
| Knowi | $20,000/yr for 5 users; custom above that, no per-query fee. | No independent or vendor TPC-DS/TPC-H benchmark public. | Not built for petabyte-scale workloads; single-vendor stack. |
Where Federation Breaks Down
Large Joins and Network Shuffle
Federated engines cannot exploit source-specific indexes beyond predicate pushdown. When a join cannot be pushed down, data shuffles across the network between workers, and high-cardinality or deep nested NoSQL joins can exhaust worker memory. Warehouses handle petabyte-scale joins more predictably because compute and data are co-located from the start.
Pricing Unpredictability
Per-TB pricing on Athena and BigQuery Omni is cheap for small, well-partitioned workloads, but an unfiltered scan of tens of TB can cost tens of dollars per query, repeated daily at scale. Denodo and Starburst Enterprise instead use sales-quoted pricing with no public rate card, making budgeting harder up front.
NoSQL and Format Lock-In
Most mainstream federation engines expose NoSQL sources as flattened SQL tables rather than querying native document structure; Denodo and Starburst both offer MongoDB connectors that translate JSON into rows. As of August 2026, Knowi appears to be one of the few engines in this set built to query nested NoSQL documents like MongoDB and Elasticsearch without that flattening step, a connector difference rather than a performance claim. Federation is also easier when an organization standardizes on an open table format: Databricks Lakehouse Federation requires Unity Catalog and Iceberg, and several Starburst/Trino connectors work best against Hive, Glue, or Iceberg catalogs.
Where Knowi Fits Best
Knowi fits teams whose data is genuinely mixed, SQL alongside MongoDB, Elasticsearch, or REST APIs, and who want federation plus a dashboard layer from one vendor instead of assembling Trino or Starburst with a separate BI tool. That matters most for teams without a dedicated platform engineering function to run and tune an open-source cluster. Standardizing how sources get modeled before they reach any query layer is also where a semantic layer earns its keep, regardless of which engine sits underneath it.
Knowi is a weaker fit for petabyte-scale workloads with heavy concurrent load, where a dedicated MPP warehouse or a tuned Trino/Starburst cluster with a real ops team will outperform a single-vendor stack. Teams already standardized on Iceberg or Delta across multiple warehouses may get more raw throughput from Starburst or Databricks Lakehouse Federation instead. For regulated workloads, on-prem or self-hosted Knowi deployments keep the AI layer and query processing inside that environment, a claim scoped specifically to self-hosted deployment rather than the SaaS product broadly.
Query Every Source. Skip the Warehouse Copy.
Knowi federates SQL, NoSQL, and REST APIs natively, decomposing each request into source-native sub-queries and joining the results without a warehouse copy. Dashboards, alerts, and natural language query run directly on top.
What you can do with Knowi:
- Join MongoDB, Elasticsearch, SQL databases, and REST APIs in one query, without flattening nested data.
- Build dashboards directly on federated results, no separate warehouse required.
- Push filters and aggregates down to each source to cut data movement.
- Ask questions in natural language across connected sources.
- Deploy in the cloud, on-prem, or hybrid, keeping query processing inside your environment where required.
- Scale to roughly 70 native connectors without adding new pipelines.
Used by SaaS, healthcare, manufacturing, and data platform teams evaluating whether to federate or centralize their next workload.
Native SQL + NoSQL Federation
No Warehouse Copy Required
Cross-Source Joins
On-Prem Deployment Available
Frequently Asked Questions
Is query federation faster than loading data into a warehouse first?
It depends on the workload. Simple lookups against live data are effectively instant, but large-scale analytics on federated sources can run slower than the same query on pre-loaded warehouse tables, especially when joins cannot be pushed down.
How much does data federation cost compared to a cloud data warehouse?
Serverless federation like Athena or BigQuery Omni bills roughly $5 per TB scanned, while warehouses like Snowflake or Redshift bill by compute credits or cluster hours plus storage. Which is cheaper depends on query patterns and how much of the workload repeats versus runs ad hoc.
Can Trino or Starburst query Snowflake and Databricks together?
Yes. Both have connectors for Snowflake and for Delta/Iceberg tables in Databricks, so a single SQL query can join a Snowflake table with a Databricks table, pushing filters down to each source.
How does BigQuery Omni pricing work for cross-cloud queries?
BigQuery Omni charges standard BigQuery rates, $5 per TB processed on-demand, with no separate AWS or Azure egress fee since compute runs inside the customer’s region. There is no published extra “Omni fee” on top of the normal bill.
What are the practical limits of query federation?
The recurring limits are network-bound shuffles on large joins, no source-side indexing advantage beyond predicate pushdown, and concurrency ceilings on self-hosted clusters. BigQuery Omni adds a specific one, recommending joins stay under roughly 60 GB per subquery.
When should we use ETL into a warehouse instead of federating?
Warehousing tends to win when you need sub-second results on very large, repeatedly-queried datasets, when source systems cannot absorb extra read load, or when downstream processes need a deterministic, versioned snapshot.
Can Knowi query MongoDB and Snowflake together in one dashboard?
Yes. Knowi’s architecture supports cross-source joins between SQL and NoSQL data, breaking a request into a native MongoDB query and a native Snowflake query, then merging the results before rendering.