Bring in a table with custom SQL

Write your own query against a connected warehouse, validate it, name the table it produces, and come back later to edit the query without rebuilding anything.

4 min readUpdated September 26, 2026

Browsing tables is the quick path into a warehouse, but some questions need a join, a filter, or an aggregate before the data is worth analyzing. The import wizard's Custom SQL tab lets you write that query yourself and treat its result as a table like any other.

Write the query

Open a saved database connection to launch the import wizard.
In the right column, switch from "Browse Tables" to the "Custom SQL" tab.
Type your query into the SQL Query editor.
Click "Validate Query", then "Estimate Rows".
Name it in the left column and finish with Import Data.

Note: The Custom SQL tab is offered for warehouse connections that can run SQL. A file-based source such as S3 has no query to write, so it shows only Browse Files.

Validate and estimate

"Validate Query" actually runs your SQL against the warehouse as a one-row sample, so the verdict is real rather than a guess at the syntax. A success reads "Query is valid" with the column count it returned; a failure shows the warehouse's own error. "Estimate Rows" reports how much data the query would bring back.

Validating is optional - the import re-checks server-side - but it is far cheaper to find a typo here than after naming and importing.

Row limits

A warehouse dataset stays live - charts query your table or your custom SQL directly - so Golden does not cap the import. If you want to bound what a query brings back, add your own LIMIT to the SQL. It no longer conflicts with anything, and the editor confirms the one you set: below the query it reads "Query includes LIMIT 1,000".

Tip: When your query ends in a LIMIT, "Estimate Rows" shows the capped figure with the full count beside it - for example "10,001 (limited from 21,932)" - so you can see both the bound and how much data sits behind it.

Naming what you get

On a fresh import the name field reads "Import Name" and names the dataset. When you are adding a query to a dataset that already exists, it reads "Table Name" instead, because the query becomes another table on the canvas rather than a new dataset - the helper text says it "Names this query's table on the canvas, so you can relate it to the tables already there".

Edit the query later

A SQL-derived table keeps its query, so you can change it without re-importing. Two ways in, both landing in the same editor:

Click the pencil in the table card's header on the data model canvas - its tooltip reads "Edit custom SQL". Only a SQL-derived table has one.
Right-click the table and choose "Edit Custom SQL".

The wizard reopens on the Custom SQL tab with your existing query already in the editor. Browse Tables and Query Builder are hidden for this trip on purpose: an edit session is about this one table, and leaving the other tabs live meant the single name field could rename the wrong thing. Adding more physical tables is still a separate action.

Tip: The Query Builder tab has an escape hatch into SQL: build a query visually, click Preview Query, then use the pencil on the "Generated SQL" block ("Edit in Custom SQL") to carry that SQL into the editor rather than retyping it.

Note: On a connection that queries live rather than importing rows, the wizard's header and its primary button say "Import Schema" - Golden records the query's shape and runs the SQL on the warehouse each time, instead of copying rows in.

If a table you expect is missing from the tree, the footer asks "Don't see your schema or table?" with a Refresh button that re-reads the schema from the warehouse - the usual causes are a cached tree or a role without access to it.