Integrations — Warehouses
NerveStax and DuckDB
Agents build and test dbt models on DuckDB, local or hosted on MotherDuck.
What we do
What NerveStax does with DuckDB
Point a project at a DuckDB file or a MotherDuck database and agents build and test its dbt models from inside a sandbox, read schemas, tables and run history, and check the project against what is really in the database. Every code change arrives as a pull request a person approves.
-
Local file or MotherDuck
A target is either a DuckDB file or a MotherDuck database reached with a service token. NerveStax works out which from the path and keeps the database name straight either way.
-
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 database.
-
Reads schemas, tables and columns
Agents list schemas and tables, read column types and row counts, and use that instead of guessing what a model can select from.
-
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.
-
Pinned to a working DuckDB version
The sandbox image pins the exact DuckDB version MotherDuck accepts, because a floating version is how a hosted connection breaks on a Tuesday for no visible reason.
-
Lands ingested tables here
A load an agent proposes from a MySQL or PostgreSQL source lands in a DuckDB or MotherDuck destination today, ready for your dbt sources to read.
Background
About DuckDB
DuckDB is an in-process analytical database that runs from a single file. MotherDuck is the hosted service built on it, where the same dbt project runs against a database in the cloud instead of on disk.
How it connects
What connecting it looks like
-
01
Choose local or MotherDuck
A path to a .duckdb file, or an md: database. Either one is enough; you do not configure both.
-
02
Add the token or path
A MotherDuck service token is stored encrypted like any other credential, replaceable but never shown back. A local path is just configuration.
-
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
- DuckDB has no GRANT system, so access is the file and the process, or the scope of a MotherDuck token. Scope the token rather than expecting SQL grants.
- Incremental models on DuckDB support append and delete+insert only. A model asking for merge will not compile, whatever NerveStax does.
- Lineage is model-level. Column-level lineage is not built.
Questions
DuckDB and NerveStax
Q01Does it work with MotherDuck?+
Yes. A MotherDuck database is a DuckDB target with an md: path and a service token, and NerveStax treats it as its own variant so identity, schemas and run history line up with the hosted database rather than a local file. The DuckDB version in the sandbox is pinned to what MotherDuck accepts.
Q02Does it run against production?+
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.
Q03Do my table rows go to the model provider?+
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.
Q04How do I limit what an agent can touch?+
With a MotherDuck token scoped to the database you want it in, since DuckDB has no grants to lean on. An agent uses the credentials on the project and there is no separate identity for its runs, so the token's scope is the boundary. Marking the project protected adds an approval on every dbt command.
Q05Can a local DuckDB file work in a sandbox?+
Yes, when the file is in the repository checkout or written there by the run itself — that is a common pattern for tests and small projects. For anything a team shares, MotherDuck or another warehouse is the practical answer, since a sandbox is destroyed when the conversation goes idle.