How Starburst Trino Executes Queries Across Hybrid Data Sources

When an analyst or BI tool runs a SQL query, Starburst Trino doesn’t move all the data into a new system. Instead, it uses a virtualized query engine to orchestrate execution across on-prem and cloud sources.

1. The query request first hits the Coordinator Node, which is the brain of Trino. It also returns the final results back to the consumer.
2. The Coordinator calls the Data Catalogue (Hive or Glue) to fetch schema and metadata.
3. It also uses the Data Location API to determine partition and file/block placement in the data sources.
4. The Coordinator parses the SQL, applies the cost-based optimizer (CBO), and prepares an execution plan. CBO is like Google Maps for queries — it figures out the fastest route to get from “query start” to “result”, based on available data and resources.
5. The execution tasks are assigned to Worker Nodes, which scale out horizontally.
6. Workers fetch the actual data directly from the source systems (on-prem DBs, HDFS, S3, Snowflake, etc.).
7. The workers process, join, and aggregate the data, then stream intermediate results back to the Coordinator.
8. The Coordinator merges everything and returns the final result set to the analyst or BI tool.

This approach allows Trino to act as a single SQL layer across heterogeneous systems, providing federation without physically consolidating all the data.

The benefit? Speed, flexibility, and no heavy ETL pipelines.

How Virtualization Works in Practice

When people hear “data is not moved”, they often wonder: how does Trino actually deliver results?

The key is to understand the difference between moved data and streamed data.

• Moved Data: In traditional ETL, data is extracted from source systems, loaded into a new platform (like Redshift, Snowflake, or a data lake), and stored permanently. Queries then run on the copy.
• Streamed Data: In Trino, data is fetched only at query time. Worker nodes connect to the sources, pull the required rows in chunks, and process them in memory (or spill to temporary disk). Once the query is complete, this data is discarded — the only thing retained is the final result set delivered to the user.

Where Results Live During Execution

Get SURESHKUMAR MUTHUKARUPPAN’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Another common doubt is: if nothing is moved, where does the data “sit” while queries run?

• During execution, intermediate results live temporarily inside the worker nodes’ memory.
• If data volume is large, workers may spill chunks to their local disks.
• Once workers finish processing, they send the final partial results back to the Coordinator, which merges them into the final answer.
• That merged result is streamed to the BI tool, SQL client, or API consumer.

Importantly:

• Trino does not persist query results by default.
• If users want the output saved, they must explicitly write it back into a target system

Why Is This Still Called Virtualization?

It might sound contradictory: if Trino pulls data, isn’t it still moving data?

The distinction is:

• With ETL, you physically centralize and store data in a new system.
• With Trino, the data stays in the original sources. Trino only “borrows” the data temporarily while executing queries, without creating a permanent copy.

From the end user’s perspective, this feels like all data is in one place:

• Analysts write a single SQL query across Redshift, MongoDB, and S3.
• They don’t need to know where each dataset resides.
• They just get a unified result, as if everything were part of one logical database.

This abstraction is what makes Trino a data virtualization engine. It provides a virtualized SQL layer across heterogeneous systems, without duplicating or relocating the data.

How End Users Experience It

For BI tools, analysts, or API consumers, the experience is simple:

• They issue a query.
• They receive the result set.
• They don’t see (or need to see) the intermediate steps of fetching from Mongo, pushing filters down into Redshift, or joining across sources.

Trino hides the complexity of distributed execution, so users interact with it just like any other SQL database — even though, under the hood, the data may be scattered across on-prem databases, cloud warehouses, and object storage.

Conclusion

Starburst Trino isn’t a database, it’s a high-performance query fabric. It gives you one SQL interface across Redshift, Snowflake, MongoDB, and more — without moving the data.