Lakeflow Declarative Pipelines vs dbt op Databricks
Een eerlijke, actuele vergelijking van de twee belangrijkste manieren om data te transformeren op Databricks: wat elk goed doet, waar het tekortschiet, en hoe u kiest.
Anton Corredoira
Wie data-pipelines bouwt op Azure Databricks loopt vroeg of laat tegen dezelfde vraag aan: transformeert u uw data met Lakeflow Declarative Pipelines of met dbt? Het eerlijke antwoord: geen van beide wint onomstotelijk. Wat past hangt af van uw team, uw data en hoeveel van de stack u zelf wilt beheren. Maar de afweging is wél scherp te maken, zeker met het landschap van 2026 in gedachten.
Eerst de naamgeving (er is veel veranderd)
Het vakgebied bewoog het afgelopen jaar snel, dus even bijpraten:
- Delta Live Tables (DLT) is hernoemd naar Lakeflow Declarative Pipelines. De kern-engine is open source gemaakt en bijgedragen aan Apache Spark als Spark Declarative Pipelines, waardoor het framework niet langer een gesloten, Databricks-only specificatie is. In de documentatie heet het product inmiddels zelfs “Lakeflow Spark Declarative Pipelines”.
- dbt Labs en Fivetran rondden hun fusie af op 1 juni 2026, waarmee ingestion en transformatie onder één dak komen.
- dbt bracht dbt Core v2.0 uit: open source onder Apache 2.0 en gebouwd op de fundamenten van de Fusion-engine, een herschrijving in Rust die sneller parseert, sneller draait en SQL echt begrijpt. De commerciële Fusion-distributie voegt daar proprietary functies aan toe. Databricks wordt door de nieuwe engine ondersteund.
Wat elk precies is
Lakeflow Declarative Pipelines (LDP) is een declaratief framework voor batch- én streaming-pipelines in SQL of Python. U declareert streaming tables, materialized views en views; Databricks bepaalt de uitvoeringsvolgorde, verzorgt incrementele verwerking, herstart na fouten en beheert de compute. Het dekt het volledige ETL-pad, inclusief ingestion en datakwaliteit.
dbt is een transformatie-framework. U schrijft modulaire SQL-SELECT-statements (models); dbt lost afhankelijkheden op met ref()/source(), materialiseert ze als tabellen, views of incremental models, en voegt tests, documentatie en een lineage-graaf toe. Op Databricks draait het via de dbt-databricks-adapter op SQL-warehouses of clusters. Het is de T in ELT; ingestion en orkestratie liggen ergens anders.
Lakeflow Declarative Pipelines
Sterke punten
- End-to-end ETL in één framework. Ingestion (Auto Loader, message buses), transformatie en serving leven samen, niet als drie losse tools.
- Batch en streaming in hetzelfde model, met een AUTO CDC API voor change data capture en SCD type 1/2 met heel weinig code.
- Ingebouwde datakwaliteit. Expectations valideren rijen en kunnen waarschuwen, droppen of falen. Sinds begin 2026 kunt u ze bovendien opslaan en versioneren in Unity Catalog en delen over pipelines.
- Automatische orkestratie. Afhankelijkheden, retries en incrementele herberekening worden voor u geregeld, met managed (en serverless) compute.
- Diepe Unity Catalog-integratie voor lineage, audit en het doorzetten van rechten, afgedwongen tijdens runtime.
Afwegingen
- Gebonden aan Databricks. Ook met de open Spark-specificatie leven de managed runtime en tooling op Databricks. Wilt u mogelijk wisselen van platform, dan is dat echte lock-in.
- Een ander denkmodel. Streaming tables versus materialized views versus flows kost tijd om eigen te maken.
- Een kleiner ecosysteem. Minder community-packages, en de conventies voor testen en documentatie zijn minder gestandaardiseerd dan bij dbt.
- Kostendiscipline nodig. Continue pipelines die blijven draaien kunnen duur worden als u er niet bovenop zit.
dbt
Sterke punten
- SQL-first met een enorme community. Een volwassen ecosysteem van packages, generieke en specifieke tests, automatisch gegenereerde docs, exposures en een semantische laag.
- Portabiliteit. Hetzelfde project kan zich richten op Databricks, Snowflake, BigQuery en meer, wat lock-in beperkt en uw investering beschermt.
- Sterke engineering-workflow. Modulariteit, versiebeheer, CI en testen zijn eersteklas, wat grote projecten onderhoudbaar houdt.
- De Fusion-engine brengt snellere lokale ontwikkeling, real-time type-checking en snellere runs, en dbt Core v2.0 is open source.
Afwegingen
- Alleen transformatie. dbt doet zelf geen ingestion of streaming; u heeft Auto Loader, Fivetran of iets vergelijkbaars nodig voor de EL, en streaming is geen kernconcept.
- Aparte orkestratie nodig. Inplannen komt van het dbt-platform, Databricks Workflows of Airflow, niet van dbt zelf.
- U beheert de compute. Op Databricks bepaalt en draait u nog steeds de SQL-warehouses of clusters waarop dbt uitvoert.
- Sommige functies zijn betaald. De cloud-IDE, scheduler en semantische laag zitten achter het commerciële product van dbt.
Kosten
Bij kosten lopen de twee het duidelijkst uiteen, en precisie loont hier.
Lakeflow Declarative Pipelines kent geen aparte licentie. U betaalt alleen voor Databricks-compute (DBU’s). Het tarief hangt af van cloud, editie en of u classic of serverless draait; reken grofweg op $0,20 tot $0,40 per DBU; de details staan op de prijzenpagina. Er komt geen prijs per seat of per developer bovenop, en u ontwikkelt in de Databricks-workspace waar u toch al voor betaalt.
dbt is gratis te draaien, maar de prettige UI niet. dbt Core is open source (Apache 2.0): u ontwikkelt lokaal of in de VS Code-extensie, orkestreert met Databricks Workflows of Airflow en betaalt alleen compute. Wilt u de managed omgeving met IDE, scheduler en semantische laag, dan komt u bij het commerciële platform uit: het Starter-plan kost $100 per developer per maand, enterprise-prijzen zijn maatwerk. Dat komt bovenop de compute die u aan Databricks blijft betalen.
Kort gezegd: bij Lakeflow betaalt u compute en niets anders. Bij dbt kan dat ook, zolang u op Core blijft. Maar de UI-gebaseerde workflow die de meeste teams uiteindelijk willen brengt reële kosten per seat met zich mee.
Naast elkaar
| Dimensie | Lakeflow Declarative Pipelines | dbt |
|---|---|---|
| Bereik | Ingestion + transformatie + serving | Alleen transformatie (T) |
| Streaming | Eersteklas, native | Geen kernconcept |
| Datakwaliteit | Ingebouwde expectations (UC-beheerd) | Tests (generiek + specifiek) |
| Orkestratie | Ingebouwd | Extern (Workflows, Airflow, dbt-platform) |
| Talen | SQL en Python | SQL (plus Jinja, Python models) |
| Portabiliteit | Databricks (open Spark-kern) | Meerdere warehouses |
| Ecosysteem | Groeiend | Groot en volwassen |
| Governance | Unity Catalog, runtime-afgedwongen | dbt lineage-graaf + integraties |
| Kostenmodel | Alleen compute (DBU’s), geen licentie | Core gratis; UI betaald per seat |
Hoe te kiezen
Kies eerder voor Lakeflow Declarative Pipelines als u volledig op Databricks zit, ingestion, streaming, CDC en datakwaliteit in één managed framework nodig heeft, en zo min mogelijk orkestratie-overhead wilt met Unity Catalog-native governance.
Kies eerder voor dbt als u een SQL-gericht team heeft, portabiliteit over meerdere warehouses belangrijk vindt, en het volwassen ecosysteem voor testen, documentatie en packages wilt met een sterke engineering-workflow, terwijl ingestion elders gebeurt.
Ze sluiten elkaar niet uit
Het meest pragmatische antwoord is vaak “allebei”. Een veelvoorkomend patroon: gebruik Lakeflow Declarative Pipelines (of Auto Loader) voor ingestion en streaming naar uw bronze- en silver-lagen, en gebruik daarna dbt om de gecureerde gold en marts in SQL te modelleren, met de bijbehorende tests en docs. Zo krijgt u native ingestion en streaming waar het telt, met daarbovenop een portabele, goed gedocumenteerde transformatielaag.
Tot slot
Kies het gereedschap dat past bij de klus voor u, niet dat met de luidste lancering. En wilt u een second opinion op uw specifieke situatie, neem dan contact op.