Compute
A compute entry answers “what runs this warehouse’s queries, and who pays for them”. Like credentials, it is a workspace-level object that warehouses point at rather than contain.
Separating it makes an ordinary arrangement expressible that previously was not. Scheduled pipeline runs and the queries a person is watching have opposite cost profiles: one wants throughput at night, the other wants a small warehouse that answers now. Bundled into the warehouse they shared one, and the only way around it was a second warehouse pointing at the same tables, with its own credential, its own connection test and its own copy of every setting.
Find them on the Warehouses page, under the Compute tab.
What compute means, per warehouse
| Warehouse | What you are choosing |
|---|---|
| BigQuery | The billing project — genuinely separate from the project the data lives in |
| Spark Lakehouse | The endpoint, separate from the catalog |
| Snowflake | Nothing to choose here — the warehouse on the connection already is the compute |
| Databricks | Nothing to choose here — the HTTP path on the connection already is the compute |
| ClickHouse | No separable compute — the server is the compute |
| Redshift | No separable compute — the cluster is the host you connect to |
Only the first two can be created, and the reason is worth stating plainly: on Snowflake and Databricks a second box labelled “Warehouse” would be the same question the connection already asks, and the two disagreeing is a support ticket nobody can read off the screen.
Creating and changing one
Add Compute asks for the warehouse type, a name, and the compute itself. The type is fixed once the entry exists — a Snowflake warehouse name cannot run a BigQuery job, so there is nothing to change it to.
Editing repoints it. Every warehouse bound to the entry starts running its queries there on its next run, including which account is billed for them, so the page names how many before you save.
Deleting is only possible once nothing points at the entry.
Pointing a warehouse at one
From the warehouse’s own page, under “Where Zeotap works”. Leaving it unset means the warehouse runs its queries on whatever its own connection names, which is what every warehouse did before these existed.
Choosing a BigQuery billing project also pins where Zeotap keeps its own working tables to the project they are already in, so they stay put rather than following the compute. That is a separate setting on the same panel if you want to move them.
Who can do what
| Permission | Allows |
|---|---|
execution_environments.read | View compute entries |
execution_environments.write | Create, rename and repoint |
execution_environments.delete | Delete an unreferenced entry |
Owners and admins hold all three. Members hold none of them: repointing an entry moves where every warehouse bound to it runs — and who is billed for it — so this page is administration. Grant execution_environments.read through a custom role if your workspace wants a member to see it.