Query Results (meta-source)

Query Results is a meta-source, not a real database connection — every organization gets it automatically, with nothing to configure and no credentials to enter. It exists to answer one question SQL normally can’t: how do you join data that lives in two different data sources?

How it works

Reference a previously-run query’s cached result as a table named query_<id>, where <id> is that query’s numeric id — then write ordinary SQL against it, including joining several of these “query tables” together:

SELECT o.*, u.name
FROM query_42 o
JOIN query_17 u ON u.id = o.user_id

Behind the scenes, arcodash loads each referenced query’s most recent cached result into an in-memory SQLite database and runs your SQL against that. This is why the join above works even if query_42 originally ran against Postgres and query_17 ran against a completely unrelated warehouse — by the time your SQL runs, both are just tables in the same temporary SQLite instance.

[!NOTE] Because the join happens in SQLite, the SQL dialect that applies is SQLite’s — not whatever dialect either underlying query’s own data source speaks. Functions or syntax specific to Postgres, MySQL, etc. won’t necessarily work here even if the source query used them.

You’re querying a cache, not live data

This is the most important caveat: query_<id> reflects that query’s last cached result, not a live read of its underlying source. If the underlying query hasn’t been run again since data changed at the source, this meta-source won’t reflect that change until the underlying query runs again (manually, or on its own schedule).

[!TIP] If a dashboard built on Query Results looks stale, check when the underlying queries it references last ran — refreshing the dashboard itself doesn’t re-run them; only running the original queries again refreshes what’s available to join against here.

Limits worth knowing

Only the single most recent cached result per distinct query is available — not history.
A query whose result has never been cached (or whose cache was cleared) doesn’t show up as a query_<id> table at all; run it at least once first.
At most 500 distinct cached results are loaded into the in-memory database per run — not necessarily the 500 most recently run ones — so an organization with more than 500 queries that have a cached result may not have every one of them available to reference at once.

Where to go next

Data sources overview — creating and managing the real connections whose results you can later join with this meta-source.