Query every backend through one SQL surface

You may need to query across databases, SaaS systems, and uploaded files within a single workflow. Once registered, all sources can be accessed through the same interface, allowing you to write queries that combine them without switching tools or environments.

How it works

Step 1 — Query Postgres through hotdata query

Here conn_app_postgres.public.orders. GitHub-backed tables use the same connection.schema.table pattern (confirm names with hotdata tables list --connection-id conn_app_github).

Our app database and GitHub are already linked here. Give me every open order—just order id and dollar total—up to 100 rows.

Heavy or routed queries may still surface async run metadata in the CLI when the engine prefers not to hold the session open until completion.

Step 2 — Query uploaded datasets like connection tables

Datasets sit in the same SQL namespace as conn_app_postgres and conn_app_github (for example datasets.main.*).

Pull the first 50 rows from my partner_accounts upload with every column included.

Step 3 — Mirror everything in the CLI for debugging

Run the open-orders check again, then show the 50 most recently updated GitHub issues (number, title, state). After that, list recent query activity so support can match what was tried.

Step 4 — Guardrails with workspace context

Optional workspace documents (for example DATAMODEL) describe joins and naming beyond raw catalog output. See Workspace context.

Who uses this

• Teams that expose one SQL interface to multiple apps or dashboards.
• Products that route agent tools through the same SQL surface across several backends.
• Internal platforms that standardize on one workspace for governed queries.