Databricks Asset Bundles vs Terraform: Wat Deploy Je Waarmee?

Een vergelijking met een twist

De vergelijking "Databricks Asset Bundles (DAB) vs Terraform" heeft een grappige eigenschap: DAB draait zelf op Terraform. Onder de motorkap genereert een bundle Terraform-configuratie om je Databricks-resources te beheren. Hoe kun je dan twee dingen vergelijken waarvan de één op de ander is gebouwd?

Het antwoord is dat ze op een verschillend abstractieniveau opereren. Terraform is een generieke Infrastructure-as-Code-tool die letterlijk alles kan beheren — van een storage account tot een Unity Catalog-grant. DAB is een doelgerichte, Databricks-native laag die het deployen van data-engineering-assets drastisch vereenvoudigt. In dit artikel zie je precies waar de grens ligt en hoe je ze het beste combineert.

Wat is Terraform (voor Databricks)?

Terraform houdt een state bij van alles wat het beheert en is de standaard voor platformteams die governance, security en reproduceerbaarheid op infraniveau willen afdwingen. Het nadeel: HCL en de breedte van Terraform vragen kennis die niet elke data engineer dagelijks gebruikt.

# main.tf — een SQL warehouse en een catalog-grant
resource "databricks_sql_endpoint" "analytics" {
  name             = "analytics-wh"
  cluster_size     = "Small"
  auto_stop_mins   = 10
}

resource "databricks_grant" "sales_read" {
  catalog    = "prod"
  principal  = "analysts"
  privileges = ["USE_CATALOG", "SELECT"]
}

Wat zijn Databricks Asset Bundles (DAB)?

De winst van DAB is developer experience voor data engineers: YAML in plaats van HCL, code en configuratie in één deploy, en slimme development/production-modes die in dev automatisch isolatie toepassen zodat collega's elkaar niet overschrijven.

# databricks.yml
bundle:
  name: sales_pipeline

resources:
  jobs:
    daily_sales_load:
      name: daily-sales-load
      tasks:
        - task_key: ingest
          notebook_task:
            notebook_path: ./src/ingest_orders.py

targets:
  dev:  { mode: development, default: true }
  prod: { mode: production }

De grens: fundering versus werklasten

Omdat beide jobs en pipelines kúnnen aanmaken, lijkt er overlap. De sleutel is opnieuw eigenaarschap per laag:

• Terraform = de fundering. Workspaces, Unity Catalog (metastore, catalogs, schemas op governance-niveau), netwerken, storage, cluster policies, SQL warehouses, secrets scopes en permissions. Dit is langlevende, gevoelige infrastructuur die het platformteam beheert.
• DAB = de werklasten erbovenop. De jobs, DLT/Lakeflow-pipelines en notebooks die data engineers dagelijks bouwen en aanpassen, samen met hun code. Snel itereren, per feature een dev-deploy.

Vergelijkingstabel

Referentie-architectuur: gebruik beide

In een volwassen opzet zijn DAB en Terraform geen concurrenten maar lagen in dezelfde stack:

• Laag 1 — Terraform (platformteam): provisiont de Databricks-workspaces, configureert Unity Catalog, netwerken, storage, cluster policies, SQL warehouses en permissions. Verandert zelden en wordt streng gereviewd.
• Laag 2 — DAB (data-engineeringteams): deployt jobs, pipelines en notebooks naar de door Terraform klaargezette workspaces. Verandert vaak en hoort bij de dagelijkse ontwikkelflow.
• CI/CD: Terraform-changes lopen via het platform-repo; bundle-deploys via het project-repo van het datateam. Beide met eigen service principals en least-privilege rechten.

Het resultaat: stabiele, gecontroleerde fundering én snelle, zelfstandige datateams. Precies de balans die je wilt op een groeiend Lakehouse-platform.

Wanneer kies je wat?

Genoeg aan alleen DAB als...

• Je een klein, Databricks-only team bent en de workspace al bestaat.
• Je vooral jobs, pipelines en notebooks wilt uitrollen, niet de onderliggende infra.
• Je snelle iteratie en een lage leercurve belangrijker vindt dan volledige infracontrole.

Je hebt (ook) Terraform nodig als...

• Je cloud-infrastructuur (storage, netwerk, IAM) en workspaces zelf beheert.
• Je Unity Catalog, permissions, cluster policies en security centraal en streng wilt afdwingen.
• Je meerdere teams en omgevingen governt en één bron van waarheid voor de fundering wilt.

Conclusie

"DAB vs Terraform" is uiteindelijk geen wedstrijd maar een werkverdeling. Terraform beheert de fundering, DAB de werklasten — en omdat DAB op Terraform draait, sluiten ze naadloos op elkaar aan. Gebruik Terraform voor wat zelden verandert en streng gegovernd moet zijn, en DAB voor wat datateams dagelijks bouwen.

Wil je deze tweelaagse opzet (Terraform-fundering + DAB-werklasten) inrichten of je bestaande Databricks-deploys professionaliseren? Neem gerust contact op — ik help je graag op weg. Zie ook de bredere vergelijking Snowflake DCM vs Databricks Asset Bundles.

Veelgestelde vragen

Draait Databricks DAB op Terraform?

Ja. Onder de motorkap genereert DAB Terraform. Als gebruiker werk je met YAML en de Databricks CLI in plaats van met HCL.

Vervangt DAB Terraform volledig?

Nee. DAB richt zich op Databricks-werklasten. Voor cloud-infrastructuur en workspace-brede governance gebruik je doorgaans nog steeds Terraform.

Kan ik DAB en Terraform samen gebruiken?

Ja, dat is de aanbevolen architectuur: Terraform voor de fundering, DAB voor de assets en code daarbovenop.

Wie gebruikt wat?

Platform-/infrateams beheren de fundering met Terraform; data-engineeringteams deployen hun jobs en pipelines met DAB.