SQL workbench

Use the SQL workbench to write queries against catalog tables, inspect execution stages, and combine data from multiple connections or Lake.

Find a table

Use Data explorer to inspect the exact table name and column types. A qualified workbench name is connection.dataset.table, for example pg.public.customers or lake.uploads.orders. Shorter names work only when unambiguous.

Write a small query

The workbench accepts a supported SQL syntax, not every source’s native syntax. Adapt this example to a real catalog table:

SELECT order_date, revenue
FROM lake.uploads.orders
LIMIT 20;

Use Run selection / statement to run one read-only statement. Errors identify syntax, missing fields, incompatible types, or access problems. Read workbench dialect and compatibility for exact restrictions.

Inspect the plan

Select Explain to review source fragments and the final combining stage. Check which filters and aggregations run at the source before starting a large query.

For multiple sources, use fully qualified table names and explicit join keys. Cross-source querying explains consistency, transfer, and costs, with worked examples.

Use SQL functions

Use calendar, ratio, and cleanup functions such as MONTH, COUNT_IF, SAFE_DIVIDE, and SAFE_NUMBER. These functions may introduce Lake processing even for a single external source.

Work with results

Inspect paginated results, download them, or use Save to Lake where available. Saved results are private snapshots and retain source permissions. Temporary results expire; see results and limits.

The public pricing page still labels the standalone SQL product as planned. This guide documents the workbench where available in your deployment.