Terraform and DABs ownership boundaries
This comparison defines ownership boundaries for Terraform and Declarative Automation Bundles (DABs). Databricks previously called DABs "Databricks Asset Bundles."
For the related platform guidance, read Databricks platform lessons.
Refreshed: 2026-08-08 — the deployment engine and the resource tables are checked against current docs. The boundary rule and the research below still date from the 2025 compile.
What changed since 2025#
Two product changes affect the tables below. Neither change affects the recommended boundary.
- Bundles no longer run on Terraform. Databricks CLI 0.279.0 added a direct deployment
engine that calls the REST API through the Go SDK. New bundles from CLI 1.3.0 use it by
default. Databricks says the Terraform deployment engine "will soon be deprecated". So the
old argument — "bundles are Terraform underneath, so the state guarantees are the same" —
no longer holds. Migrate an existing bundle with
databricks bundle deployment migrate. - Bundles can now deploy Unity Catalog catalogs and external locations. Those two, plus Genie spaces, instance pools, and AI Search endpoints, need the direct engine and do not work on the Terraform engine at all. Catalogs and external locations stay in the Terraform column below by choice, not because bundles cannot do it. The reason is change risk and repository access. Bundles usually live in a repository that data engineers can change.
One gap closed: bundle plan -o json now reports a per-field diff and explains what
triggered each action, and bundle deploy --plan plan.json replays an approved plan. The
"terse failure output vs Terraform" complaint in
Community best practices is stale.
Sources, checked 2026-08-08: Migrate to the direct deployment engine.
Sources#
- Alex Ott - Terraform vs. Databricks Asset Bundles
- Databricks Community - Asset bundle vs terraform
- Junaid Effendi - Terraform vs Asset Bundles for Databricks Workflows
- New Math Data - Databricks Asset Bundles Deployment Guide
- Databricks Community - Automate SQL Deployments with Terraform & DABS
- Reddit r/databricks - "What are some things you wish you knew?"
- What are Declarative Automation Bundles? (Azure docs)
The Boundary Rule#
Terraform = "What does the workspace look like?" (infra, identity, catalog structure, security) DABs = "What runs inside the workspace?" (jobs, notebooks, pipelines, compute, secrets)
Keep in Terraform (infrastructure/platform layer)#
| Resource Type | Why Terraform |
|---|---|
| Azure VNet, Subnets, NSGs, NAT | Cloud networking |
| Azure Resource Groups | Cloud infra |
| Azure Storage Account (ADLS Gen2) | Cloud storage |
| Databricks Workspace | Platform provisioning |
| Access Connector | Azure IAM bridge |
| Azure Role Assignments | Cloud IAM |
| Entra ID Groups | Identity provider |
| Databricks Account Groups | Account-level identity |
| Unity Catalog Metastore | Account-level UC |
| Storage Credential | Account-level UC |
| Catalog | Platform-level UC object |
| Schemas + External Locations | Platform-level UC objects |
| Grants (metastore, catalog, schema, external location) | Security and governance. Read Unity Catalog grants first. |
| Volumes (external, managed) | Platform storage |
Catalog grants need one owner. DABs writes its own grants on catalogs and schemas
when it deploys, so authoritative databricks_grants (plural) wipes them on every apply.
Use databricks_grant (singular) on each object that DABs also changes. Read
Unity Catalog grants for the full rule.
Move to DABs (application/project layer)#
| Resource Type | Why DABs |
|---|---|
Jobs (databricks_job) |
Workflow orchestration, tightly coupled to notebook code |
Notebooks (databricks_notebook) |
Code artifacts that live with the source code |
Shared Compute Clusters (databricks_cluster) |
Data teams need to iterate on config without TF deploys |
SQL Warehouses (databricks_sql_endpoint) |
Data teams configure sizing/scaling |
Secret Scopes (databricks_secret_scope) |
Application secrets tied to specific pipelines/jobs |
| Cluster Permissions | Tied to cluster lifecycle |
| Job Permissions | Tied to job lifecycle |
| Cluster Policy Permissions | Tied to compute governance |
| Lakeflow Spark Declarative Pipelines (formerly DLT) | Data engineering workflows |
| ML Experiments / Models | Data science workflows |
Key Insights from Research#
- ~~DABs uses Terraform internally — same state management guarantees.~~ Superseded. True when this was written, false now. See "What changed since 2025" above. Judge bundles on the interface and the ownership boundary, not on a shared engine.
- Two repositories add coordination work — practitioners report duplicate work and Terraform state conflicts when Terraform owns application resources.
- Repository access affects the boundary — developers can usually change bundle repositories. Keep sensitive resources in a restricted Terraform repository.
- Data team autonomy — DABs let data engineers manage workload schedules and compute without a Terraform pull request.
- Use each tool for its native scope — use DABs for supported workload resources. Use Terraform for platform resources and cloud infrastructure.