Query engines
Which engine runs your query, and what that means for speed and permissions.
Three surfaces read the lakehouse on different engines, which explains the speed and memory you get and why a large query behaves differently in a notebook than in SQL Lab. For the wider picture, see the Engines table in core concepts.
Rule of thumb: notebooks pull data to your code; Trino pushes your query to the data. Small and exploratory goes in a notebook, large and repeated over Trino.
The three engines
| Catalog Preview | DuckDB in a notebook | Trino | |
|---|---|---|---|
| What it is | The portal reading a few rows straight from a table’s files. | An in-process SQL engine running inside your notebook session. | A shared, scale-out SQL engine that runs next to the data. |
| Where it runs | In the portal. | In your notebook session. | On shared cluster nodes. |
| What moves | A handful of rows. | The data you scan, pulled into your session. | Only the result comes back. |
| Memory limit | None to worry about — it is a sample. | Your notebook session’s memory. | Not bound by your session. |
| Reach for it when | You want to see whether a table holds what you think. | Python, iterating on joins and aggregations, charts in the notebook. | SQL over the lakehouse, queries behind charts, data too large to pull into a session. |
| Surfaces | Data Catalog preview tab. | Notebooks. | SQL Lab, Superset charts. |
Catalog Preview is not a query: it reads about the first 20 rows from the table’s current snapshot, so it cannot filter, join or aggregate. Use it to confirm a table’s shape, then query it for real.
Permissions are the same everywhere
All three read as you — switching engines never widens what you can read. See how access works.