Does dbt Still Leave You to Land the Data Yourself?
dbt is a transformation tool by design. It assumes the raw data is already in the warehouse, so the landing step is a second product with a second bill, even now that Fivetran and dbt Labs are one company. A warehouse platform that ingests and models in one place closes the gap without a second contract.
The data warehouse automation solution trusted by data teams across industries
Does this sound familiar?
- Before a single dbt model can run, a separate product has to have landed the data, and that product has its own pricing, schema and failure modes.
- The pipeline is two systems with a handoff in the middle, and every incident starts with working out which side it is on.
- Landing schemas change under the dbt sources, and the first sign is a failed run the next morning.
- The staging layer in dbt exists mostly to undo decisions the ingestion tool made about shape.
dbt, now one company with Fivetran, is explicitly a transformation tool. It does not extract, and it does not load from outside the warehouse. That is a clean design decision, and it leaves every team with a second product to procure, configure and pay for before the first model runs.
Why the gap costs more than it looks
- Two products, two bills. Ingestion is priced on its own terms, by rows or by connector, and transformation on its own, by seats or by usage. Neither knows about the other.
- Two schemas. The ingestion tool lands data in its shape. dbt’s staging layer then spends its first models converting that shape into one the project can use.
- One handoff, all the incidents. A schema change on the landing side is discovered as a failed dbt run. Ownership of the fix is a discussion before it is a ticket.
- A merger does not fix the architecture. Since 2026-06-01 Fivetran and dbt Labs are one company, and still two products with separate pricing. The landing schema is still not the model.
Where ingestion belongs
- Next to the model. The tool that knows the business keys and the history rules is the tool best placed to load the source the way the model needs it.
- Priced with the warehouse, not per row. Loading through the platform runs on compute you already own, with no second metering.
- With one owner. A pipeline with no handoff has no argument about which side broke.
What changes with Datavault Builder
Datavault Builder ingests and models in the same platform: batch, delta and CDC loads from databases, files, REST APIs, NoSQL and Python sources, with streams such as Kafka arriving as micro batches, mapped directly into hubs, links and satellites.
- No second product for landing. Sources connect to the platform that generates the warehouse. One contract, one tool, one place to look when something fails.
- No shape to undo. The landing table is mapped to the model as it arrives. There is no intermediate schema that a staging layer has to reverse.
- Schema changes are handled where they land. A new column is a mapping update, not a broken run the next morning.
- The delivery layer follows in the same tool. Marts and data products are built by drag and drop on the semantic layer, with versioned business rules. Teams that keep operations in dbt get the dbt models generated from the same model.
- The long tail can stay. A managed connector is still a fine choice for small SaaS sources. The vault does not care which route a table took.
What to decide
List the sources where the ingestion tool’s schema and the dbt staging model that undoes it are maintained by two different people. Those are the sources to land through the platform first.
See It Running on One of Your Sources
Book a free demo and bring the connector that costs you the most, in money or in time.
Three Steps to a Pipeline You Control
-
Land through the platform
Datavault Builder ingests in batch, delta or CDC from databases, files, REST APIs, NoSQL and Python sources.
-
Model on the landed data
Sources map into hubs, links and satellites in the same tool, with no handoff and no second schema to reconcile.
-
Deliver from the same model
Marts and data products by drag and drop, or generated dbt models if operations stay in dbt.
How Datavault Builder Takes the Friction Out of Ingestion
-
Ingestion is built in
Batch, delta and CDC loads from databases, files, REST APIs, NoSQL and Python sources, with streams such as Kafka arriving as micro-batches. Same platform that generates the warehouse, no second invoice.
-
Your schema, not the vendor's
Source tables are mapped to a Data Vault 2.0 model you designed. A new column or a renamed table changes a mapping, not a chain of post-load scripts.
-
Only deltas move
Hubs, links and satellites load what changed. Full reloads stay in staging instead of being reprocessed downstream every night.
-
History is kept by design
Every change is retained as it arrives, so as-was reporting works even where the source overwrites its own rows.
-
Code you never hand-write
Loading, historization and lineage are generated from the model in real time and run natively on Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle or PostgreSQL.
-
One platform, up to nine tools fewer
Modeling, ETL, CI/CD, documentation and lineage in one place. That is what makes 14.7 minutes from requirement to production possible.
Recognized by BARC in The Data Fabric Survey 26
Meet Our Expert
Twenty minutes with our Sales Director, and an honest answer on whether this fits your stack.
Matt Collett
Sales Director
Great, pick a time that works for you:
Other Problems This Series Covers
-
The dbt Trade-Off: Code Sprawl, Hidden TCO, and the Case for Automated Modeling
dbt brought software engineering to SQL, and teams are right to want that. The trade is a transformation layer that grows in code, in cost and in compute, on top of an ingestion tool that is still a separate product. A generated Data Vault takes that whole layer off the code base. It does not need dbt, but it can be combined with it.
-
Is Your dbt Run Quietly Driving Up Warehouse Compute?
dbt executes everything in the warehouse, so a full refresh where an incremental would do, or a table materialization that rebuilds every night, shows up as credits, not as an error. Incremental logic is optional in dbt. In a generated Data Vault it is the only way loads are written.
-
Does Your dbt Project Have More Models Than Anyone Can Explain?
ref() makes a new model a one line decision, and a project of hundreds of loosely governed SQL files is the result. Changing a business key upstream then means finding every model that inherited it. The fix is not more tests. It is a model that generates the structure instead of accumulating it.
Questions and Answers
- The merger completed on 2026-06-01. Fivetran and dbt Cloud remain separate products with separate pricing, and the schema Fivetran lands is still not the model dbt needs. Both companies say tighter integration will follow. Today the gap is between two products from one vendor instead of two vendors.
- Batch, delta and CDC loads from databases over JDBC, files and REST APIs, NoSQL stores through the Trino connector and Python sources through a gRPC connector. Streams such as Kafka arrive as micro batches through Trino. CDC is part of the Enterprise tier.
- No. Keep it for the long tail of SaaS sources if it is cheap there, and land the heavy or awkward sources through the platform. The vault sits behind both.