Integrations — Warehouses
NerveStax and Trino
Agents build and test dbt models on Trino, across the catalogs it fronts.
What we do
What NerveStax does with Trino
Point a project at Trino and agents build and test its dbt models on a development target from inside a sandbox, read the catalogs, schemas and tables the cluster fronts, and check the project against what is really there. Every code change arrives as a pull request a person approves.
-
Builds and tests models on a dev target
dbt run, test and build execute in the sandbox against the target the project configures. On a protected project each one stops for approval before it touches the cluster.
-
Reads catalogs, schemas and tables
Catalog, schema and table are the three levels an agent navigates, so it knows which catalog a model actually reads from on a cluster fronting several at once.
-
Names tables conservatively
Identifier limits belong to the backing catalog, not to Trino, so NerveStax assumes the most restrictive one it supports rather than risking a silently truncated name.
-
Profiles and samples a table
When an agent profiles or samples a table, the rows it retrieves go to your model provider under your key. Result rows are not masked, so treat sampling as you would any query.
-
Finds drift against the project
The catalog a dbt run produces is compared with the project, so a model whose shape in the lakehouse no longer matches the code is visible before something downstream breaks.
-
Write SQL waits for a person
Read queries run freely. Anything that is not a read against a source connection is treated as a write and stops for approval before it executes.
Background
About Trino
Trino is an open-source distributed SQL engine that queries across catalogs — Iceberg, Hive, object storage or a database — from one cluster. Many lakehouse teams model on it with dbt.
How it connects
What connecting it looks like
-
01
Create a Trino user
We recommend a principal limited to the catalogs and schemas the project reads and builds into, rather than one with cluster-wide rights.
-
02
Add the connection
Add the host, port, catalog and credentials in settings. They are stored encrypted, and can be replaced but never read back.
-
03
Point a project at it
Give the dbt project the target it should build into. That development target is where agent work is tested before you see it.
-
04
Mark production projects protected
Protection makes every dbt command on that project wait for a person's approval, with the command, selector and target shown.
Scope
What this does not cover
- Incremental behaviour follows the backing catalog: a Hive or Glue-backed catalog cannot rename, so the strategies available to a model depend on where it lands.
- There is no separate least-privilege identity for agent runs — an agent uses the credentials on the project.
- Lineage is model-level. Column-level lineage is not built.
Questions
Trino and NerveStax
Q01Does it run against our production cluster?+
Not without a person. dbt commands run in a sandbox against the target the project configures, normally a development one, and on a project you mark as protected every dbt run, test and build waits for approval. Code reaches production only through a pull request your team merges.
Q02Does it understand which catalog a model uses?+
Yes. Trino identity is catalog, schema and table, and NerveStax keeps all three, so one cluster fronting Iceberg, Hive and a JDBC catalog does not collapse into a single namespace in the record of your models, runs and lineage.
Q03Do my table rows go to the model?+
Only when an agent queries, samples or profiles a table — then the rows it retrieves are in the answer it reads, capped per call and not masked. Those calls go to the model provider you chose, under your own key. The rest of the time it works from schemas, dbt artifacts and run results.
Q04Can it reach a cluster inside our network?+
It has to be reachable from wherever the sandbox runs. On hosted NerveStax that is the sandbox provider's network; self-host and run the sandbox tier in your own cluster and connections come from your network instead, which is the usual answer for an internal cluster.
Q05Which dbt adapter does it use?+
dbt-trino, pinned in the sandbox image so a build resolves the same way next month as it does today. Your project's own dbt configuration is what decides the target, the schema and the materialisations; NerveStax does not rewrite your profiles.