Snowflake DCM vs Databricks Asset Bundles (DAB): Declaratief Deployen Vergeleken

Waarom dit onderwerp er in 2026 toe doet

Een paar jaar geleden was het deployen van een dataplatform vaak nog een verzameling losse SQL-scripts, handmatig aangeklikte jobs in een UI en een gedeelde map met notebooks. Dat schaalt niet. Datateams willen dezelfde discipline die softwareontwikkelaars al jaren hanteren: versiebeheer, code review, reproduceerbare omgevingen (dev → test → prod), automatische deployments via CI/CD en een betrouwbare rollback.

Zowel Snowflake als Databricks hebben hier inmiddels een native, first-party antwoord op. Bij Snowflake heet dat DCM (Database Change Management), georganiseerd in zogeheten DCM Projects en aangestuurd via de Snowflake CLI. Bij Databricks heet het Asset Bundles (DAB), aangestuurd via de Databricks CLI. Beide zijn declaratief en command-line-gedreven. De grote vraag die ik in projecten steeds vaker hoor: "Wat is nu eigenlijk het verschil, en welke heb ik nodig?"

Het korte antwoord — en meteen de belangrijkste nuance van dit artikel — is dat ze elkaar maar gedeeltelijk overlappen. Ze lossen allebei "declaratief deployen" op, maar op een andere laag van je dataplatform. Laten we ze eerst los bekijken en daarna eerlijk naast elkaar leggen.

Wat is Snowflake DCM?

DCM staat voor Database Change Management: een declaratieve manier om de structuur van je Snowflake-objecten te beheren. In plaats van migratiescripts te schrijven die stap voor stap beschrijven hoe je van versie A naar versie B komt, beschrijf je in DCM de gewenste eindtoestand van je objecten. Snowflake bepaalt vervolgens zelf het verschil met de huidige toestand en voert alleen de noodzakelijke wijzigingen door.

De motor onder DCM is Snowflake's CREATE OR ALTER-semantiek. Je schrijft een objectdefinitie alsof je 'm voor het eerst aanmaakt; Snowflake brengt de bestaande versie idempotent in lijn met die definitie. Een DCM Project bevat één of meer definitiebestanden plus een manifest, en je kunt per omgeving een configuration meegeven (bijvoorbeeld andere database-namen of warehouses voor dev en prod).

Een typische workflow ziet er zo uit:

# 1. Een DCM-project initialiseren
snow dcm create my_warehouse_project

# 2. Definitiebestand: gewenste eindtoestand (definitions/sales.sql)
CREATE OR ALTER SCHEMA analytics.sales;

CREATE OR ALTER TABLE analytics.sales.orders (
    order_id      NUMBER,
    customer_id   NUMBER,
    order_total   NUMBER(12,2),
    order_status  VARCHAR,
    created_at    TIMESTAMP_NTZ
);

# 3. Eerst een plan (dry-run): wat zou er wijzigen?
snow dcm plan my_warehouse_project --configuration prod

# 4. Toepassen
snow dcm deploy my_warehouse_project --configuration prod

Het grote voordeel: je Git-repository wordt de bron van waarheid voor je databasestructuur. Geen "script 014_add_column.sql" meer die je in de juiste volgorde moet draaien en die kapotgaat als iemand handmatig iets aanpaste. DCM concurreert daarmee vooral met imperatieve migratietools als schemachange, Flyway en Liquibase — maar dan native, zonder externe tooling.

Wat zijn Databricks Asset Bundles (DAB)?

Databricks Asset Bundles pakken een ander probleem aan. Een Databricks-project bestaat zelden alleen uit tabellen: je hebt jobs, Lakeflow/DLT-pipelines, notebooks, ML-experimenten, model serving endpoints en dashboards. Die assets wil je samen, reproduceerbaar en omgevings-bewust uitrollen. Dat is precies wat DAB doet: het is Infrastructure as Code voor je Databricks-werklasten.

Onder de motorkap genereert DAB Terraform om de resources aan te maken en bij te werken, maar als gebruiker werk je met overzichtelijke YAML. Je definieert targets (omgevingen), variables en presets, en de CLI synchroniseert je code mee. Een vereenvoudigd voorbeeld:

# databricks.yml
bundle:
  name: sales_pipeline

variables:
  warehouse_id:
    description: SQL warehouse voor de job

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
    workspace:
      host: https://prod.cloud.databricks.com

# Valideren, deployen naar prod en draaien
databricks bundle validate
databricks bundle deploy --target prod
databricks bundle run daily_sales_load --target prod

DAB deployt dus niet alleen configuratie, maar ook de code en de werklasten die op je platform draaien. De mode: development en mode: production zorgen voor slimme defaults (in dev krijgen objecten bijvoorbeeld een gebruikersprefix zodat collega's elkaar niet overschrijven).

De cruciale nuance: ze deployen niet hetzelfde

Dit is waar veel vergelijkingen de mist in gaan. Snowflake DCM en Databricks DAB zijn geen één-op-één concurrenten. Ze opereren op verschillende lagen:

• Snowflake DCM beheert de databasestructuur — de DDL-staat van je objecten. Het beantwoordt de vraag: "Hoe ziet mijn database eruit?"
• Databricks DAB beheert werklasten en code-assets — jobs, pipelines, notebooks. Het beantwoordt de vraag: "Wat draait er op mijn platform?"

In de praktijk betekent dit: als je organisatie zowel Snowflake als Databricks draait, gebruik je ze gewoon allebei — DCM voor je Snowflake-schema's, DAB voor je Databricks-jobs. Je "kiest" pas tussen filosofieën als je een platformkeuze of een deploy-strategie bepaalt.

Vergelijkingstabel

CI/CD-integratie

Beide tools zijn gebouwd voor pipelines. Het patroon is in beide gevallen hetzelfde: een service principal / machine-account authenticeert, de CLI draait een plan op een pull request en een deploy bij een merge naar de hoofdbranch.

Voor Snowflake DCM draai je in je GitHub Actions- of Azure DevOps-pipeline de Snowflake CLI met key-pair authenticatie. Een PR draait snow dcm plan zodat reviewers precies zien welke DDL-wijzigingen eraan komen; de merge draait snow dcm deploy tegen de juiste configuration.

Voor Databricks DAB draai je databricks bundle validate op de PR en databricks bundle deploy --target prod bij release. Omdat DAB ook de code meeneemt, deploy je in één stap zowel je notebooks als de jobdefinities die ze aanroepen.

Drift: wat als iemand handmatig iets wijzigt?

Een van de grootste praktische verschillen tussen declaratieve en imperatieve tooling zit in de omgang met drift — het verschijnsel dat de live omgeving afwijkt van wat er in je repository staat, bijvoorbeeld omdat iemand 's nachts een kolom heeft toegevoegd via de UI om een incident op te lossen.

Bij Snowflake DCM is het uitgangspunt simpel: de definitie in je repo is de waarheid. Draai je een deploy, dan brengt DCM het live object idempotent in lijn met je definitie. Een handmatig toegevoegde kolom die niet in je definitie staat, vraagt om bewust beleid: wil je dat DCM die verwijdert (strikte reconciliatie) of behoudt? Dit is precies waarom je in productie altijd eerst een plan draait — zodat een onverwachte drop niet als verrassing komt.

Bij Databricks DAB werkt het vergelijkbaar, maar via de onderliggende Terraform-state. DAB houdt bij welke resources het beheert. Een job die buiten de bundle om handmatig is aangemaakt, valt buiten de scope en wordt met rust gelaten; een job die DAB beheert en die handmatig is aangepast, wordt bij de volgende deploy teruggezet naar de bundle-definitie. De gouden regel op beide platforms: wijzig beheerde objecten nooit handmatig in productie — wijzig de definitie en deploy opnieuw.

Rollback en veiligheid

Declaratief deployen voelt comfortabel totdat een wijziging misgaat. Hoe rol je terug? Hier verschilt de aanpak fundamenteel van imperatieve migraties, waar je een expliciet "down"-script schrijft.

• Snowflake DCM: rollback betekent meestal "terug naar de vorige definitie en opnieuw deployen". Omdat je definities in Git staan, is dat een git revert gevolgd door een deploy. Let op: een kolom-drop is destructief — DCM kan de structuur herstellen, maar niet de data. Combineer daarom met Snowflake Time Travel en zero-copy clones om data veilig te stellen vóór ingrijpende wijzigingen.
• Databricks DAB: omdat een bundle code én configuratie samen deployt, is teruggaan naar een vorige Git-tag en opnieuw deployen vaak voldoende om jobs en pipelines te herstellen. Voor data zelf leun je op Delta Lake time travel en RESTORE.

Testen en kwaliteit

Geen van beide tools is een testframework — en dat hoort ook niet. Hun rol is het betrouwbaar uitrollen van wat je gedefinieerd hebt. Kwaliteit borg je in lagen eromheen:

• Structuur: de plan/validate-stap in je pull request is je eerste test — reviewers zien exact welke wijzigingen eraan komen.
• Transformaties: hiervoor gebruik je doorgaans dbt met data tests (uniqueness, not-null, relationships) of, op Databricks, de verwachtingen (expectations) in DLT/Lakeflow-pipelines.
• Integratie: deploy eerst naar een dev- of staging-omgeving, draai een smoke test op echte data, en promoot pas daarna naar productie.

Het mooie van declaratief werken is dat je test- en productieomgeving uit dezelfde definities ontstaan. De kans dat "het op test wel werkte maar op prod niet" wordt daarmee veel kleiner — een veelvoorkomende bron van incidenten in handmatig beheerde platforms.

Hoe ziet zo'n repository eruit?

Een concreet beeld helpt. Een Snowflake DCM-project organiseer je vaak per domein, met definities en een manifest:

snowflake-platform/
├── manifest.yml              # DCM-project + configuraties (dev/prod)
├── definitions/
│   ├── databases.sql
│   ├── sales/
│   │   ├── schema.sql
│   │   ├── tables.sql        # CREATE OR ALTER TABLE ...
│   │   └── views.sql
│   └── finance/
│       └── ...
└── .github/workflows/deploy.yml

Een Databricks-bundle organiseer je rond je werklasten, met de code ernaast:

databricks-platform/
├── databricks.yml            # bundle, variables, targets
├── resources/
│   ├── jobs.yml
│   └── pipelines.yml         # DLT/Lakeflow-pipelines
├── src/
│   ├── ingest_orders.py
│   └── transform_sales.py
└── .github/workflows/deploy.yml

Zie je het patroon? Snowflake DCM draait om objectdefinities, Databricks DAB om werklasten plus code. Beide stoppen alles in Git en laten een pipeline het zware werk doen.

Wanneer kies je wat?

Kies (ook) voor Snowflake DCM als...

• Snowflake je primaire warehouse is en je je schemabeheer uit losse migratiescripts wilt halen.
• Je een native oplossing wilt zonder externe tools als schemachange of de Terraform-provider te onderhouden.
• Je teams baat hebben bij een leesbaar diff (plan) in code review vóór elke DDL-wijziging.

Kies (ook) voor Databricks Asset Bundles als...

• Databricks je platform is en je jobs, DLT/Lakeflow-pipelines en notebooks reproduceerbaar wilt uitrollen.
• Je code én werklasten in één deploy wilt meenemen, met nette dev/prod-isolatie.
• Je af wilt van handmatig aangeklikte jobs en versnipperde Terraform.

Conclusie

Snowflake DCM en Databricks Asset Bundles laten zien dat beide grote dataplatforms dezelfde richting op bewegen: weg van handwerk, naar declaratieve, version-controlled, CI/CD-vriendelijke deployments. Ze zijn alleen geen directe concurrenten — DCM beheert je databasestructuur, DAB beheert je werklasten en code.

Voor data engineers is de boodschap helder: omarm op beide platforms de declaratieve aanpak. Zet je Snowflake-schema's onder DCM, je Databricks-assets onder DAB, en combineer waar nodig met dbt voor transformaties. Het resultaat is een dataplatform dat je met een gerust hart kunt aanpassen, reviewen en uitrollen — precies de volwassenheid die moderne datateams nodig hebben.

Wil je je deploy-strategie voor Snowflake of Databricks naar dit niveau tillen, of twijfel je over de juiste opzet van CI/CD en omgevingen? Neem gerust contact op — dan denk ik graag mee.

Veelgestelde vragen

Is Snowflake DCM een vervanger voor dbt?

Nee. dbt richt zich op transformaties (de SELECT-logica die je tabellen en views vult), terwijl DCM de structuur van je objecten beheert. Ze vullen elkaar aan: DCM zet de fundering, dbt bouwt de modellen erbovenop.

Vervangt Databricks DAB Terraform?

Voor je Databricks-werklasten (jobs, pipelines, notebooks) grotendeels wel — DAB genereert daarvoor zelf Terraform. Voor onderliggende cloud-infrastructuur (storage accounts, netwerken, IAM) gebruik je doorgaans nog steeds losse Terraform. We gaan hier dieper op in in een vervolgartikel over DAB versus Terraform.

Kan ik DCM en DAB tegelijk gebruiken?

Ja, en in een multi-platform organisatie is dat de norm: DCM voor je Snowflake-schema's, DAB voor je Databricks-assets. Ze bijten elkaar niet omdat ze op verschillende platforms en lagen werken.

Wat is het verschil met schemachange?

schemachange is imperatief: je schrijft genummerde migratiescripts die stap voor stap beschrijven hoe je omgeving verandert. DCM is declaratief: je beschrijft de gewenste eindtoestand en de engine bepaalt zelf de wijzigingen. Declaratief schaalt beter en is minder foutgevoelig bij teams.

Werken ze met GitHub Actions en Azure DevOps?

Beide zijn CLI-gebaseerd (snow dcm en databricks bundle) en draaien daardoor in vrijwel elke CI/CD-pipeline. Authenticatie regel je met een service principal of key-pair, zodat deployments volledig geautomatiseerd verlopen.