You decide when dbt upgrades
The dbt version is pinned per project, from 1.9 to 1.12. You try the next version before production moves to it. On dbt's platform the version moves on a release track, and Snowflake offers its own short list.
Compare
auradata compared with dbt platform, Snowflake and Databricks
The same dbt project, five ways to run it in production. Here is what you get with each, row by row, taken from each vendor's own documentation.
Why teams choose auradata
Every test has a history you can see
Open a test and see its results across runs, and freshness per source. Elsewhere that history is an API call or something you build from JSON files.
One runner for six warehouses
Snowflake, BigQuery, Databricks, Redshift, Postgres and MotherDuck. The warehouse-native options run one warehouse each.
Pull request checks with nothing to set up
Every pull request gets a GitHub check that builds only what changed into its own schema. Snowflake and Databricks leave that pipeline for you to write.
Alerts that reach a person
Email and webhook alerts with rules per project. Snowflake task errors can only go to a cloud message queue.
Nothing to operate
No scheduler, no workers, no artifact bucket, no secrets file. Connect the repository and the warehouse. The sample project runs in about 20 seconds with no warehouse at all.
Row by row
| auradata beta | dbt platform | Snowflake native | Databricks native | Do it yourself | |
|---|---|---|---|---|---|
| Who moves the dbt version | You. Pinned per project, dbt 1.9 to 1.12 | dbt Labs, on a release track you choose. A minor version can no longer be pinned docs | You pick from Snowflake's supported list: 1.9, 1.10 and 1.11 when checked docs | You. Any dbt-databricks version from PyPI docs | You |
| Test and freshness history | Each test's results across runs, and freshness per source, in the console | Latest test status in the catalog. History of up to 20 runs through an API, on Starter and above docs | Not documented | Not documented | Yours to build from run_results.json and sources.json |
| Warehouses | Snowflake, BigQuery, Databricks, Redshift, Postgres, MotherDuck | Snowflake, BigQuery, Databricks, Redshift generally available. Others in beta docs | Snowflake only docs | Databricks. The docs conflict on other targets docs | Any adapter |
| Pull request checks | A GitHub check on every pull request. Builds only what changed, with defer, into its own pr_<n> schema | Built in for GitHub and GitLab, Azure DevOps on Enterprise. Builds what changed into a temporary schema and drops it when the pull request closes docs | Not built in. The docs describe a pattern you run in your own CI docs | Not documented | Yours to build: keep the production manifest, build what changed with defer, clean up schemas |
| Alerts | Email and webhook, with rules per project | Email, Slack and Microsoft Teams per job. Outbound webhooks on Starter and above docs | Task errors go to Amazon SNS, Azure Event Grid or Google Pub/Sub. Email and webhook are not supported for task errors docs | Email and webhook destinations on job events docs | Yours to script |
| Run history | Every run kept with its logs by step and its dbt artifacts | Run history for 365 days and artifacts per run. Artifact retention not documented docs | Execution history view, logs in the event table, artifacts docs | Artifacts archived per run. Retention not documented docs | Whatever you copy out of target/ after each run |
| Scheduling | Cron per job | Intervals, set hours or cron, in UTC. One job can start when another finishes docs | A Snowflake task around EXECUTE DBT PROJECT. Needs a user-managed warehouse, and two runs of one project cannot overlap docs | A dbt task in a Lakeflow Job, on the job's schedule docs | cron, a GitHub Actions schedule, or an Airflow DAG that you write |
| Docs and lineage | dbt docs generated by any job you set to do so. Lineage in the console | dbt Catalog on Starter and above, updated after each production run. Column-level lineage on Enterprise docs | Not documented | Not documented | Host dbt docs yourself |
| What you operate | Nothing | Nothing docs | A warehouse for the task, a Git integration, and an external access integration if you pull packages docs | A SQL warehouse plus compute for the dbt process docs | The scheduler, the secrets, the artifact store, the alerting |
Scroll sideways to see all five columns.
auradata is in beta, with no credit card needed. Not in the beta yet: GitLab, Slack and Teams alerts, automatic clean-up of pull request schemas, and starting a run from an outside API.
Sources
Every cell about another product comes from that vendor's own documentation, and the "docs" link in the cell opens the page it came from. dbt platform was checked on 2026-09-19, Snowflake and Databricks on 2026-09-18. "Not documented" means we could not find it in the vendor's docs. If we got something wrong, write to hello@auradata.dev and we will fix it.
Try it on your own project
No credit card. We are onboarding a few teams a week, and the sample project builds in about 20 seconds with no warehouse.