Cross-source querying

Cross-source querying combines tables from different connections or a connection and FastBI Lake in one SQL workbench query. FastBI resolves the inputs, runs source fragments, and combines their results.

It is different from asking Analysis to compare results from two sources in a conversation. A workbench join has explicit SQL join keys and produces one relational result.

Before you start

You need analyst access, an active organization, and access to every contributing source. Confirm each table and column in Data explorer, then use the displayed qualified name. The workbench uses a supported SQL syntax.

Join PostgreSQL and BigQuery

Assume pg.public.customers has one row per customer, and bq.sales.orders contains orders with the same customer ID domain.

SELECT c.id AS customer_id,
       c.country,
       SUM(o.amount) AS revenue
FROM pg.public.customers AS c
JOIN bq.sales.orders AS o ON o.customer_id = c.id
GROUP BY c.id, c.country
ORDER BY revenue DESC
LIMIT 100;

Here pg and bq are example connection names, not built-in aliases. Replace them with catalog names. Use compatible join-key types and an agreed meaning for the customer ID; matching column names alone are not enough.

Run and review the query

FastBI checks table access and query validity, reads the selected sources, and combines the results. Give each output column a unique name. Use result pages, download the data, or save a completed result to Lake where offered. Large queries remain subject to source capacity and usage limits.

Reduce transfer with independent CTEs

For cross-source work, an outer WHERE or LIMIT does not guarantee that it will be pushed into every source scan. A bare source relation may be extracted with SELECT * before the final query applies its conditions.

Put selective filters, needed columns, and safe source-side aggregates in an independent single-source CTE. See cross-source examples for a concrete pattern.

Review the plan to confirm where filters take effect. Moving a calculation across a join can change its result.

Inspect Explain

Use Explain before running a large query. Check:

• Which connection each source fragment reads.
• Which filters and aggregations actually appear in the source SQL.
• Whether functions or a cross-source join add a Lake stage.
• The dependencies between stages and the final output aliases.

The execution graph describes how FastBI plans the query. It does not establish that every source contains fresh data or that multiple sources represent the same point in time.

Consistency and costs

Each source is read at its own execution time. Cross-source queries do not create an atomic snapshot across independent databases. For a reproducible report, use stable reporting periods or snapshots supplied by the sources and document their refresh times.

Your connected source may charge for query usage. FastBI processing can also add usage charges. Read pricing examples and inspect the plan.

Permissions and saved results

FastBI rechecks access during execution and when results are read. Losing access to a source can prevent use of a derived result.

Save to Lake creates a private saved dataset with contributing-source permissions retained. Saving a query result is not a way to bypass access controls. See results and limits for expiration and saved-table naming.