Integrations — Ingestion sources
NerveStax and MySQL
Point an agent at a MySQL database and it proposes the load as a pull request.
What we do
What NerveStax does with MySQL
An agent connects to your MySQL database, reads what is in it, and proposes a load: which tables, which columns to sync on, and how often. That proposal arrives as a pull request. Once it runs, source schema changes are detected and classified, so a new column or a changed type reaches you as a decision, not a broken load.
-
Reads the source database
An agent lists tables and columns, checks sizes and candidate sync columns, and reports what a load would actually involve before anyone commits to it.
-
Proposes the load as a pull request
Tables, sync columns and cadence become configuration and a schedule in your repository, reviewed like any other change. Nothing starts loading because an agent thought it should.
-
Detects source schema changes
Added, dropped, renamed and retyped columns are classified: informational, needs review, or needs a re-sync. A new column that looks sensitive is always put in front of a person.
-
Installing and running need approval
Installing, running, stopping or re-syncing an ingestion stops for a person every time. These are irreversible actions, so they are refused rather than auto-approved when nobody is there.
-
Lands tables your models can read
Loaded tables land in the destination as their own schema, declared as dbt sources, so the models built on them are ordinary code in your project.
Background
About MySQL
MySQL is the open-source relational database behind a great many operational systems. Data teams usually need its tables copied into a warehouse before anything can be modelled on top of them.
How it connects
What connecting it looks like
-
01
Create a read-only user
A MySQL user with read access to the tables you want loaded. Credentials are stored encrypted and no screen shows them back.
-
02
Add the connection
Add host, port, database and user in settings, and check that the database is reachable from where the sandbox runs.
-
03
Ask an agent to plan the load
It reads the database, proposes tables, sync columns and a cadence, and explains what each choice means for the first run.
-
04
Review the pull request
The load is configuration in your repository. Approve it, then approve the install, and the first run is scheduled like anything else.
Scope
What this does not cover
- Beta, and narrow: MySQL and PostgreSQL are the source databases today, and a load lands in a DuckDB or MotherDuck destination.
- Change data capture from the binlog is not built. Loads are incremental on a sync column, or a full copy.
- MySQL is supported as a source to load from, not as a warehouse to build dbt models in.
Questions
MySQL and NerveStax
Q01Which sources can NerveStax load from?+
MySQL and PostgreSQL, and this part of the product is in beta. If you need another source, tell us — the loading layer is designed to take more, but we would rather list the two that work than a roadmap.
Q02Where does the data land?+
In a DuckDB or MotherDuck destination today, in its own schema, declared as dbt sources so your models read it as normal. That is a real limitation of the beta rather than a preference, and it is the first thing we expect to widen.
Q03Can an agent start loading on its own?+
No. Installing an ingestion, running one, stopping one or re-syncing a stream each wait for a person, and they are the class of action that can never be auto-approved: with nobody present they are refused, not allowed through. The configuration itself lands as a pull request first.
Q04What happens when the source schema changes?+
The change is detected per stream and classified. An added column is informational unless the table is column-filtered or the name looks sensitive, in which case a person reviews it. A dropped column or suspected rename needs review, and a type, nullability or key change needs a re-sync — which you approve.
Q05Does it read my rows?+
Loading moves rows from the source to the destination; the model provider is not in that path. It sees the plan, table and column names and the report of what ran. Rows reach the model only when you ask an agent to query, sample or profile a table, and then they go to your provider under your key.