There is no warehouse, and you do not want one yet
The join across Postgres, MySQL and SQLite happens in a staging database created for that one execution and destroyed with it. Nothing is loaded anywhere first, so there is nothing to keep in sync.
No warehouse required · sources read in place · agent as author
Honest comparison
datapipelines.co vs dbt
The short version: if your data is already in a warehouse and the job is to model it, use dbt. Its whole design — models as SELECT statements, lineage from references, tests and generated docs — assumes one warehouse that everything has already been loaded into. We assume the opposite: the data is still in the operational databases it was written to, and the question crosses them.
Read this first
Use dbt instead when…
- Everything is in one warehouse already. dbt transforms in place, inside the engine, and that is the fastest and cheapest way to do it when the data is there.
- You are building a modelling layer. Staging models, marts, a lineage graph the whole team reads, generated documentation. That is a discipline, and dbt is the tool that carries it.
- Data tests are part of the deal. Uniqueness, not-null, referential and custom tests, run alongside the models. We do not have an equivalent, and would not pretend a validation rule is one.
- Your analytics engineers own the workflow. dbt's ergonomics are built for people writing SQL in a repository, not for an agent calling tools.
The other case
Use this instead when…
The sources are operational databases
Eight dialects, each with its own adapter and type mapping — the databases your applications actually write to, not a warehouse they were exported into.
An agent is the author
Introspect, create a template, create a pipeline, execute, read rows — the whole loop over MCP tools. dbt's authoring surface is a repository and a CLI, which is a different shape of collaboration.
The credential story has to hold up
Read-only datasources enforced at save and at execution, one scoped revocable key per agent, and an audit log entry for every tool call.
What we deliberately do not claim
- Not a modelling framework. There is no
ref(), no automatic lineage graph across models, no generated documentation site. - Not a testing framework. Pipelines validate structurally at save time; they do not assert facts about your data.
- Not a warehouse tool. Snowflake, BigQuery and Databricks are not among the dialects. If that is where your data lives, dbt is the answer and we are not in the running.
The Airflow comparison → · The cross-database join → · Supported dialects →
Asked before
The dbt comparison, in questions
Do I need a warehouse for this?
No — and that is the fork with dbt. The join across Postgres, MySQL and SQLite happens in a staging database created for that one execution and destroyed with it; nothing is loaded anywhere first. Staging is docs/staging.md §1.
Which sources can it read?
The operational databases applications write to — the dialect catalog covers eight dialects: the seven remote JDBC engines plus the lake's Parquet and Iceberg — each with its own adapter and type mapping, read where they live. The catalog is docs/datasources.md §4.1.
Is an agent the author here?
That is the intended shape: introspect, create a template, create a pipeline, execute, read rows — the whole loop over MCP tools, with a person releasing what the agent drafts. dbt's authoring surface is a repository and a CLI, a different shape of collaboration. The tools are docs/mcp-server.md §6.1.
What is the credential story?
Read-only datasources whose write-shaped uses are refused at save time and again at execution, one scoped revocable key per agent, and an audit log entry for every tool call — the checks an agent-facing warehouse pipeline needs. The read-only flag is docs/datasources.md §5.7.
See the no-warehouse join on real data
The demo joins Postgres, MySQL, SQLite and Parquet on S3 in one pipeline — the workload dbt would need a warehouse in front of, run without one.