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 of models as SELECT statements, lineage from references, and 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. So this is an alternative to dbt only for that case, not a replacement for it where a warehouse already exists.

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…

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.

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 revocable key per agent holding the role chosen at its creation, never more than its creator's own, 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 → · Dagster vs Airflow, and where Prefect sits → · 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 so the whole loop runs 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.2.

What is the credential story?

Read-only datasources whose write-shaped uses are refused at save time and again at execution, revocable agent keys that are identities of their own, each holding the role its creator chose and never more than the creator's own (docs/auth.md §7.5), and an audit log entry for every tool call. Those are 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.

Run the demo The join, with its SQL