Queries
A saved query is SQL plus a typed parameter list. It's the single source of truth every visualization and dashboard draws from — get the number right once, in one place, and everything downstream follows.
Anatomy of a query
Every query has a stable key you reference it by, a readable name and description, the SQL body itself, and a list of typed parameters. Charts and dashboards don't copy the SQL — they run the query, so there's exactly one definition to maintain.
-- key: sessions-by-day
SELECT date_trunc('day', created) AS day,
count(*) AS sessions
FROM events
WHERE type = 'session'
AND app = :appId
AND created >= :from
GROUP BY 1 ORDER BY 1Typed parameters
A parameter isn't just a placeholder — it declares its type, so a date range is a date range and an id list is an array. The same query serves one app or a whole fleet; you just change the inputs.
Git-backed queries
A query can bind to a SQL file in a Git repository and sync both ways. Push a change and the query updates in Studio; edit it in Studio and it commits back to the file, with author info.
Caching
Opt a query into result caching and each distinct set of parameters is cached and refreshed on an interval by a background job. A dashboard loads from cache instantly, and consumers can tell a cached result from a live one and see when it was last computed.
Keep exploring
How events become queries, charts, and dashboards.
Events arrive from your apps and land in the warehouse — inspectable live.
Bind a query to a chart, then lay charts out on a grid that shares parameters.
Grouped errors, stack traces, and AI-generated root-cause hints.