Query Federation
Executing a single query across several underlying systems without moving the data, and the performance ceiling that pushdown determines.
A federation engine presents many sources as one and splits a query across them. Nothing is copied, so there is no pipeline to maintain and no staleness — which is genuinely attractive for exploration, for joining a small reference table to a large one, and as a transitional layer during a migration.
Performance is governed by pushdown: how much of the filtering, projection and aggregation the engine can delegate to each source. Where pushdown works, only the result crosses the network. Where it does not, the engine pulls raw rows and processes them itself, and a join between two large remote tables becomes a transfer of both.
The failure that catches teams is that this is invisible in the query. The same SQL is fast or catastrophic depending on whether the predicate could be pushed, and the difference is in the plan rather than in the statement.
The other constraint is that federation puts analytical load on operational databases. A query that would be routine in a warehouse can lock tables in the system of record, which is why read replicas are a precondition rather than an optimisation.