The query editor is where a question becomes a number. It runs against the lake, it is read-only by design, and everything it can reach is a table you already have access to.
The editor completes table and column names from the lake's metadata, so a typo shows up as a name that will not complete rather than as an error after a long run.
select
toStartOfMonth(created_at) as month,
count() as orders,
round(avg(total_amount), 2) as average_order
from lake.orders
where created_at >= toDate('2026-01-01')
group by month
order by monthEvery run reads real data. Three habits keep a query cheap:
select count() on the same filters tells you whether the
question is about ten rows or ten million.| Run | What it costs |
|---|---|
select count() with the same filters | One narrow scan, returns immediately |
| A grouped aggregate over a month | The volume actually in that month |
| A join to an unbounded table | Both sides, in full |
A saved query belongs to a workspace, not to the person who wrote it. Saving it under a name that
says what it answers - orders-by-month, not query-7 - is the difference between a shared asset
and a private note.
Cmd/Ctrl + S save Cmd/Ctrl + Enter run Cmd/Ctrl + K command palette
Important
Sharing a query shares its results, not the credentials behind it. A reader who cannot see the underlying tables gets an error on run, which is the intended behaviour and not a bug to work around by exporting the result.
A saved query can run on a schedule and write its result to a table or send it to a webhook. The schedule is the connector's own cron syntax, and a scheduled run records the same sync metadata as a connector run - so the same question ("did it run, and when") has the same answer.
:::card When a scheduled query fails
The failure is attached to the run, not to the query. The next scheduled run does not wait for a retry: it runs on time, and the previous failure stays visible in the run list until someone looks at it. Set a notification on the schedule if nobody looks. :::