Turn raw tables
into trusted
models.

Daspire Transform compiles version-controlled SQL models against the raw tables you already landed — incremental, tested, and lineage-aware. Build staging, marts, and a metrics layer in the warehouse where your analysts already live. dbt-compatible. No orchestration glue. No stale dashboards.

Build your first model → See how it works Compiles against your raw schema
Live DAG · production project · last run 3m ago
48 models · 214 tests · 9.1s compile
Raw · landed12
raw.shopify_orders
source · 5m
raw.stripe_charges
source · 5m
raw.klaviyo_events
source · 15m
Staging22
stg_orders
view · typed + renamed
stg_payments
view · deduped
stg_customers
view · pii masked
Marts11
fct_orders
incremental · merge
dim_customers
table · rebuilt
Metrics3
net_revenue
sum(amount) − refunds
repeat_rate
2nd+ orders / customers
Median compile
9.1sec
to plan and push down a 48-model project against the live warehouse
Incremental builds
94%
of runs touch only changed rows — not full-table rebuilds
Tests on every run
214checks
uniqueness, not-null, accepted-values, referential, and custom SQL
Lineage
100%
column-level, parsed from SQL — no manual graph to maintain
— Inside the Transform engine

Four mechanics
that turn SQL
into a data product.

Transform isn't a notebook and it isn't a black box. It's the modeling layer that lives in your warehouse: version-controlled SQL, materialized the cheapest correct way, tested on every run, with lineage parsed straight from the code. Here's what that buys you in practice.

01 · SQL models

Write a SELECT. Daspire makes it a managed table.

Models are just SQL files with ref() and source(). Daspire resolves dependencies, builds the DAG, and compiles to native warehouse SQL — no rows ever leave Snowflake or BigQuery.

02 · Tests & contracts

Every run is a green-or-red gate. Bad data never reaches a dashboard.

Declare uniqueness, not-null, accepted-values, and referential tests in YAML — or write custom assertions in SQL. Daspire runs them on every build and halts the downstream DAG the moment one fails.

03 · Column-level lineage

Trace any metric back to the raw column that made it.

Daspire parses the SQL — not your comments — to build a column-level graph. Click net_revenue and see every model, join, and source it flows through, plus what breaks if you drop it.

04 · Incremental materialization

Build the cheapest correct way. Touch only what changed.

Pick view, table, or incremental merge per model. On a 40M-row fact table, an incremental run rewrites the last hour — not the last two years. Daspire generates the merge key and the predicate for you.

Start from a model,
not a blank file.
Commerce packs included.

Every Daspire model pack is a version-controlled set of staging models, marts, and tests tuned to a commerce source — maintained in lockstep with the connectors that feed them. Fork it, override it, or run it as-is. The lineage stays intact either way.

Compiles into Your warehouse · native SQL
Snowflakemerge · streams
BigQuerymerge · partitions
Databricksdelta · merge
Redshiftupsert
Postgreson conflict
DuckDBlocal dev
— Missing a source? Request a connector and we'll ship it within 14 days. Browse all integrations →
— Why warehouse-native

Scattered SQL is
a liability.
Models are an asset.

The logic that defines "revenue" shouldn't live in a BI tool's saved query, a scheduled notebook, and three analysts' heads. Daspire Transform makes it one version-controlled, tested, lineage-aware model — compiled where the data already is.

— The old way · ad-hoc SQL

Dashboards that each define "net revenue" a slightly different way.

  • Business logic scattered across BI saved queries and notebooks
  • No tests — a bad join ships straight to the exec dashboard
  • Full-table rebuilds every night, warehouse bill climbing
  • "What feeds this number?" takes an afternoon to answer
  • Change a column and find out what broke in production
— Daspire · warehouse-native models

One definition. Tested every run. Traceable to the raw column.

  • Every metric is a version-controlled model — reviewed in a pull request
  • Tests gate every build; failures halt the downstream DAG
  • Incremental materialization rebuilds only what changed
  • Column-level lineage answers "what feeds this?" instantly
  • Compile-time checks catch a breaking change before it merges
— Author it your way

SQL, YAML, or the
visual builder.
Same DAG underneath.

Write models in the SQL you already know, declare tests and metrics in YAML, or compose the graph in the visual builder. Every path compiles to the same lineage-aware DAG and runs against your warehouse.

— Ship it like software

Models you can put through code review.

Transform treats every model as versioned, tested, deployable code — with the CI gates and audit trail a regulated team expects.

01 · CI / CD

Every pull request runs the affected DAG against a staging schema.

Slim builds compile only changed models and their children — green check before merge, not after.

02 · Run observability

Per-model timing, row deltas, and test results on every build.

When a model slows down or a test flips red, you see the run, the diff, and the blast radius downstream.

03 · Governance

Column-level access, PII tags, and masking carried through lineage.

Tag a source column as PII once; Daspire propagates the policy to every model that touches it.

04 · Auditability

Every build is a signed commit — who, what, when, and the compiled SQL.

Reproduce any table at any point in time from the run log. Auditors reconcile to the commit.

Questions we get
before procurement does.

If yours isn't here, ask in chat — we don't gatekeep technical conversations behind a sales call.

Is this just dbt with a new coat of paint?

Daspire Transform is dbt-compatible — point it at your existing dbt project and it runs. What you add on top: managed compile + run infrastructure, column-level lineage parsed automatically, a built-in metrics layer, and CI that runs the affected DAG on every pull request. You keep your SQL; you stop maintaining the orchestration around it.

Does my data leave the warehouse to be transformed?

No. Every model compiles to native SQL and runs as pushdown inside Snowflake, BigQuery, Databricks, or your warehouse of choice. Daspire orchestrates the run and reads metadata — the rows never move.

What does "incremental" actually cost me to run?

On an incremental model, Daspire generates the merge predicate so a run rewrites only rows newer than the last build — typically minutes of warehouse compute, not a nightly full rebuild. You pick view, table, or incremental per model; switch any time.

How does lineage stay accurate without manual upkeep?

Daspire parses the compiled SQL on every build to derive column-level lineage — there's no separate graph to maintain. If a model's SQL changes, its lineage updates on the next run, and impacted downstream models are flagged before they break.

Can analysts and engineers work in the same project?

Yes. Models are git files reviewed in pull requests, so analysts contribute SQL while engineers own the framework, tests, and CI. The visual builder lets less-SQL-fluent contributors compose models that compile to the same DAG.

Do I need Daspire Extract & Load to use Transform?

No — Transform runs against any raw tables already in your warehouse, however they got there. It pairs naturally with Extract & Load (the raw tables arrive lineage-ready), but it's not a requirement.

— Stop maintaining glue

Write one model.
Watch it ship
to every dashboard.

14-day free trial — no credit card. Point Daspire at your warehouse, fork a commerce model pack, and run your first tested build in minutes.

Build your first model → Book a 20-min demo dbt-compatible · runs in your warehouse