Lakehouse overview
Catalogs, schemas, and the Lakehouse surface.
Lakehouse is the SQL side of Databasin — a full warehouse surface where you query data that's been pipelined in, explore it in a proper editor, and run it across multiple engines from one place.
If Databasin One is "ask a question," Lakehouse is "know the answer and want to express it precisely in SQL."
The pieces
SQL Editor
A multi-tab SQL editor built on Monaco — the same engine behind VS Code. Tabs each keep their own query, results, and run state; the toolbar collects panel toggles under View and versioned scripts under Script; and the results pane can filter, profile, chart, and export what it's showing.
It has its own guide: The SQL editor.
Open the SQL editor from a project
Object Explorer
A tree view of everything you can query: catalogs → schemas → tables → columns. Browse what's available without guessing, and right-click a table for its engine-correct DDL. Toggle it from View → Object Explorer.
Saved Queries and saved scripts
Two related things. Saved Queries is your personal list of named queries — open it from View → Saved Queries. Scripts (under the Script menu) are saved on the server, versioned on every save, and shareable with teammates.
Notebooks
The long-form surface: a sequence of cells mixing SQL, Python, Spark, and markdown, with a Jupyter-style keyboard model, .ipynb import and export, version history, and scheduled runs.
It has its own guide too: Notebooks.
Catalogs and connectors
A catalog in Lakehouse maps to a connector:
- Every lakehouse engine (Trino, Doris, Spark, DuckDB) shows up as one catalog.
- Inside that catalog, you see whatever schemas and tables the engine exposes.
- Some connectors pull in external sources as read-only catalogs (e.g. Postgres, Snowflake).
- On Trino and Doris, sources you've made live appear under the
livecatalog — queryable with nothing synced. See Live connections.
So when you see warehouse.public.orders in a query, it's: catalog → schema → table.
The engines
A project can have more than one lakehouse engine at a time. The native set is Trino, Doris, Spark, and DuckDB; Databricks is supported too, as an external/federated connection rather than a native lakehouse engine.
| Engine | Best for |
|---|---|
| Trino | Interactive SQL and federated queries across catalogs. The default. |
| Doris | Real-time OLAP — low-latency, high-concurrency interactive analytics and BI. |
| Spark | Heavy ETL and large-scale processing. |
| DuckDB | Small-to-medium data; fast single-node prototyping. |
| Databricks | Querying an existing Databricks workspace from the same editor. |
The mechanics of switching engines — and which ones stream results — live in Multi-engine SQL. Doris is new enough to have its own guide: Apache Doris.
Clusters
Behind the scenes, Trino, Spark, and Doris answer queries from a running cluster — the editor calls it your workspace. Clusters cost credits while running and sleep when idle:
- When it's asleep, the editor toolbar shows Start workspace — click it and you're running in about a minute. A sleeping workspace never starts just because you hit Run.
- It stays warm for a while so follow-up queries are instant.
- It sleeps automatically after a stretch of no activity.
DuckDB is single-node and doesn't ride a managed cluster the same way. The toolbar indicator walks you through the states — Start workspace when asleep, "Starting workspace…" while it boots, then Connected. See Clusters, wake and sleep.
Things that differ from a generic SQL editor
Streaming results
On Trino and Doris, results stream in as they're produced, so you can start reading the shape before the query finishes. Spark, DuckDB, and Databricks return their results in a batch when the query completes.
Query limits (optional)
A limit results toggle in the toolbar appends LIMIT 1000 to interactive queries. It only touches SELECT, WITH, and VALUES statements — DDL, DML, and SHOW run untouched. A cheap guardrail against accidentally SELECT *-ing a huge table.