A team federates a legacy reporting database that takes about ninety seconds to answer a typical aggregate query. They are surprised the federated version is no faster. Why?
Select an answer to reveal the explanation.
Short Explanation
Federation moves the query to the data, not the performance. If the source needs ninety seconds, you get ninety seconds plus network. It’s a convenience and consistency feature, not an accelerator—when speed is the requirement, you have to ingest.
Full Explanation
Federation gives you a single place to write queries against many sources; it does not change what those sources are capable of. Work delegated to a slow remote system takes as long as that system takes, and network round trips add to it. The correct response when latency is unacceptable is to ingest the data into the lakehouse, where a query engine can work against optimised table formats on object storage.
The claim that federated queries are always executed twice, once to plan and once to run, is incorrect because planning does not require executing the query. Plans are built from metadata and statistics.
The claim that the engine caches only the first thousand rows of a federated result, forcing repeated fetches, is incorrect because there is no thousand-row limit of that kind. Results stream according to the query, and the described behaviour is not how federated reads work.
The claim that federation disables predicate pushdown, so every query becomes a full table scan, is incorrect and reverses the actual design goal. Connectors push filters and projections down to the source wherever the source supports them, precisely to reduce the amount of data crossing the network.
For the exam, remember that federation trades performance for freshness and simplicity; ingestion trades freshness for performance.