Query Engines
Engines that query data they do not own. Coordinators and workers, pushdown, vectorized execution, and the real limits of federating a query across systems.
Engines that answer SQL over storage they do not own — what that separation buys, and every guarantee it quietly hands back.
Coordinator to workers to sources to partial results to merge — and the four places a query dies that a single-node engine never has.
Push the filter down to the reader so less is read at all — and learn the identical-looking query where it silently does not happen.
Read only the columns the query needs. The cheapest optimisation a columnar format offers, and the one `SELECT *` throws away.
If the remote system can filter, aggregate or limit, do the work near the data and move less — and know exactly which of those your connector actually supports.
One SQL statement across several systems. Genuinely useful, and it gives up consistency, predictable latency, optimiser competence and control of the load you impose.
Operators that process a batch of column values per call instead of one row at a time — and why that changes what the CPU is able to do.
Modern engines let you express both with one API. The authoring surface converged; latency, state and completeness semantics did not.