Superp Logo
Home » Databricks of Fabric?
Actueel + + + + +

Databricks of Fabric?

Ronald Konijnenburg

Notities van 1.950 kilometer snelweg, geschreven terwijl ik een WhatsApp-thread van mijn Powerdobs-collega’s verwerkte op de terugweg uit Spanje.

Het meeste wat we “weten” is folklore

Ik reed net terug uit Spanje. Negentienhonderd kilometer, twee dagen, en een telefoon die op de passagiersstoel bleef trillen met een thread die mijn collega’s bij Powerdobs zonder mij waren gestart. Een welkome afleiding van het weggedrag dat ik onderweg zag, het verbaast me hoe snel iedereen weer in de ratrace schiet zodra ze achter het stuur kruipen.

De vraag die in die thread centraal stond:
Hebben we ergens een feitelijke, onderbouwde vergelijking tussen Databricks en Microsoft Fabric, iets dat we een klant kunnen voorleggen zodat die de juiste keuze kan maken?

Het is een betere vraag dan hij eruitziet. Wat volgde was een lijst met de gebruikelijke argumenten, elk eerlijk voorzien van hoeveel de schrijver er zelf in geloofde. Code-first. Big data. Kosten. Vendor lock-in. Volwassenheid. Power BI. Grotendeels herhaald, grotendeels ongecontroleerd.

Het ongemakkelijke deel: ik had die lijst zelf kunnen schrijven. Ik heb die lijst zelf geschreven, tegenover klanten. Ik kan tien verschillen tussen deze twee platforms opnoemen en ik geloof er geen één volledig. Ik herhaal wat ik op een conferentie hoorde, of in een vendor deck las, of absorbeerde van iemand die het van iemand anders absorbeerde. Dat is geen advies. Dat is folklore met een logo erop.

En toch heb ik het zelf ook gedaan. Genoeg reden om er serieus naar te kijken.

Na twee dagen snelweg en een stapel documentatie denk ik dat zo’n vergelijking niet bestaat. Het antwoord zit niet in de platforms, het zit bij de klant. Er blijft wel wat over: een handvol argumenten dat overeind blijft als je het opzoekt. Verrassend weinig.

Ergens rond Beaune, probeer de Chardonnays daar eens, echt de moeite, stopte ik met de thread lezen als een groepsgesprek en begon ik hem te lezen als een onderzoeksopdracht. Dit stuk is het denken van mijn collega’s, getoetst aan de documentatie, met mijn eigen conclusies erop. De goede delen zijn van hen. De te zelfverzekerde delen zijn van mij.

Eerst de folklore, met een cijfer erbij

Laat me mijn eigen huiswerk nakijken. Dit zijn de argumenten die ik bij klanten heb gebruikt, en wat ik er nu van denk.

  • “Databricks is code-first.” Zwak. Het was een echt onderscheid in 2021. Beide platforms bieden nu notebooks, SQL en low-code pipelines. Dit argument bestaat nog vooral als uitspraak over cultuur, niet over functionaliteit.
  • “Databricks is beter voor big data.” Twijfelachtig. Beide draaien op Apache Spark. Dit is geen schaalargument, het is een argument over tuning en controle en het moet ook zo worden geformuleerd.
  • “Fabric is goedkoper.” Mogelijk waar op instapniveau. Ik heb het nooit tot op het einde doorgerekend, inclusief mijn eigen team. Kosten zijn bewust moeilijk te doorgronden en dat is een keuze van de leverancier.
  • “Vendor lock-in.” Lock-in, schmock-in. Beide platforms slaan op in open tabelformaten. De lock-in is reëel, maar zit niet waar mensen wijzen.
  • “Databricks is volwassener.” Waar, met een datum erbij. Volwassenheidsargumenten verouderen sneller dan wat dan ook in deze vergelijking, precies waarom we moeten stoppen ze te herhalen zonder ze te checken.
  • “Power BI past beter bij Fabric.” Waar, en nog steeds het sterkste commerciële argument. Ook zwakker dan zes maanden geleden. Twijfelachtig. Beide draaien op Apache Spark. Dit is geen schaalargument, het is een argument over tuning en controle en het moet ook zo worden geformuleerd.

Twee van de zes houden stand. Als ik de klant was, wilde ik dat weten voordat iemand een architectuur voor mij tekent.

De claims die de documentatie overleven

  1. SaaS versus niet-SaaS is het scherpste structurele verschil en het slijt
    Hier kwamen mijn collega’s als hardste argument uit, en ik ben het eens: Fabric is een SaaS-platform, Databricks nadrukkelijk niet. Bij een van onze opdrachten kostte het opzetten van de Databricks-infrastructuur (networking, identity, storage) weken meer dan iemand had begroot.

    Maar de eerlijke versie van dit argument heeft een houdbaarheidsdatum aan beide kanten.

    Databricks maakte serverless workspaces in maart 2026 algemeen beschikbaar op Azure: geen VNet-ontwerp, geen subnetreeksen, geen NAT-gateways, geen afstemming met het netwerkteam voordat het eerste notebook draait. Azure heeft ook aangegeven klassieke workspace-aanmaak met een door Databricks beheerde VNet te willen afbouwen. De kloof sluit. Dicht is het nog niet. Serverless kent regio- en featurebeperkingen die je per geval moet nakijken. Maar het gat wordt kleiner.

    En aan de andere kant: de SaaS-ness van Fabric werkt perfect, tot het moment dat je security officer binnenstapt. Schakel workspace-level private link in en je verliest OneLake security, workspace monitoring en de govern-tab van de catalog. Shortcuts naar storage achter private endpoints worden niet ondersteund. In bepaalde tenant-regiocombinaties stoppen Spark-jobs met private link ingeschakeld. Pipelines en managed private endpoints combineren niet op de manier die mensen aannemen.

    SaaS spaart je dat werk dus niet uit. Bij Fabric komt het later, op het moment dat security concreet wordt. Bij Databricks staat het vooraan, voordat je iets hebt om te laten zien. Voor veel mid-market klanten is dat vooraan-stuk precies wat ze niet kunnen absorberen.
  2. Het versie-achterstandsargument is controleerbaar, en grotendeels opgelost
    Dit was vroeger eenvoudig: Fabric draaide een oude Spark, Databricks een actuele. Hier staat het nu daadwerkelijk.

    Fabric’s GA-runtime is 1.3 — Spark 3.5, Delta Lake 3.2. Runtime 2.0 is in public preview met Spark 4.1, Delta Lake 4.2, Java 21 en Python 3.13. Databricks Runtime 18 is algemeen beschikbaar op Spark 4.1, met 18.2 uitgebracht in mei 2026.

    Dus: ongeveer één runtime generatie verschil op GA-niveau, niet de meerdere jaren die het verhaal suggereert. Aan de uitvoerkant is Fabric’s Native Execution Engine gebouwd op Apache Gluten en Velox, een gevectoriseerd C++-pad, conceptueel de tegenhanger van Photon. Gepubliceerde benchmarks plaatsen het in dezelfde buurt als Photon, waarbij Photon een voorsprong houdt op workloads waarvoor Databricks specifiek heeft geoptimaliseerd.

    Wat betekent: “Databricks is sneller” kan dus niet meer zomaar op een slide. Wil je het beweren, dan moet je het op je eigen workload aantonen.
  3. Kosten: twee verschillende faalpatronen, geen winnaar
    Fabric verkoopt gedeelde capaciteit: elke workload: pipelines, Spark, warehouse, Power BI, trekt uit dezelfde pool, uitgemiddeld over tijd en als één eenheid beperkt. Het faalpatroon is één slecht geschreven notebook dat het dashboard van de CFO vertraagt.

    Microsoft sluit die kloof. Autoscale Billing voor Spark is GA en verplaatst Spark naar dedicated serverless compute, gefactureerd per gebruik, buiten de gedeelde capaciteit. Surge protection stelt achtergrondverbruiklimieten in op capaciteits- en workspaceniveau. Capacity overage laat je door een piek heen betalen, tegen ruwweg drie keer het pay-as-you-go-tarief voor het overschot.

    Dat laatste is een verzekeringspremie, en moet ook zo worden geprijsd.
    Databricks meet per workload, per DBU, per seconde, waarbij klassieke compute een aparte VM-rekening toevoegt. Je ziet daardoor beter waar het geld heen gaat. Wat er aan het eind van de maand uitkomt, is minder goed te voorspellen.

    Mijn favoriete detail uit het onderzoek: ik zocht de gepubliceerde prijzen op voor dezelfde Fabric F64 in vier verschillende vergelijkingsartikelen die zich allemaal als gezaghebbend presenteren. De cijfers verschillen bijna een factor twee. Als vier bronnen het niet eens worden over de lijstprijs van één SKU, heeft citeren geen zin meer. Zelf narekenen dus.
  4. Het Power BI-argument is reëel, maar de voorsprong is smaller
    De F64-drempel waarboven rapportgebruikers geen per-user-licenties meer nodig hebben, bepaalt de SKU voor organisaties met duizenden rapportlezers vaker dan de computeprijzen dat doen. Direct Lake is uitstekend. Dat is niet veranderd.

    Wat wel is veranderd: mirroring van Azure Databricks Unity Catalog naar OneLake is algemeen beschikbaar, Databricks kan Unity Catalog-beheerde tabellen nu rechtstreeks in OneLake opslaan, en je kunt vanuit de Databricks catalog explorer naar Fabric publiceren. Databricks als engine en Fabric als beheerde consumptielaag is nu een ondersteunde architectuur, geen workaround.

    Met één kanttekening die op elke slide hoort waar dit patroon verschijnt: Unity Catalog-rechten reizen niet mee met de mirror. Je implementeert toegangscontrole opnieuw aan de Fabric-kant. Twee beveiligingsmodellen, door mensen gesynchroniseerd, voor altijd. Dat kost structureel tijd, en het is te meten. Zulke dingen wil ik in een klantgesprek hebben liggen.
  5. Purview versus Unity Catalog is een categorievergissing
    Ze concurreren niet om dezelfde taak. Unity Catalog beheert de Databricks-omgeving: toegangscontrole, lineage, technische metadata. Purview beheert alles: on-premises, Azure, SaaS en ook Databricks. De meeste serieuze Azure

    Databricks-omgevingen draaien beide. Ze in tegenovergestelde kolommen op een vergelijkingsslide zetten is een teken dat de slide is gemaakt door iemand die geen van beide in productie heeft beheerd.

De vragen die ik liever stel

Als er geen enkele feitelijke vergelijking bestaat en ik denk nu dat die er niet kan zijn, omdat de doorslaggevende variabele de klant is, niet het platform, dan zit onze waarde in het stellen van betere vragen. Dit zijn de vragen die mijn collega’s naar boven brachten:

  • Wie beheert dit op een dinsdagmiddag over achttien maanden? Niet wie het bouwt. Wie het draaiend houdt.
  • Wat kent het team al? Een team dat vloeiend is in ADF en T-SQL heeft een kortere weg naar Fabric. Hoewel Databricks goed integreert met ADF, dus dit is richtinggevend, niet beslissend.
  • Wat is de realistische levensduur van dit platform, en wat moet het daarbinnen bereiken? Bij vijf jaar kies je iets anders dan bij vijftien jaar.
  • Wat eisen security en toegangsbeheer daadwerkelijk? Niet in theorie. Op papier.
  • Is de machine learning-ambitie reëel, of is het een slide? Wees hier meedogenloos. De meeste organisaties hebben niet het ML-programma dat ze beschrijven in het intakegesprek.
  • Wat is de exitstrategie? Wat mij betreft de beste regel uit deze hele thread: Microsoft maakt de start laagdrempelig, onze taak is de exit laagdrempelig te houden. Lock-in is geen eigenschap van het platform. Het is een gevolg van de keuzes die je erin maakt. En dat is precies waar een goede partner zijn meerwaarde bewijst.
  • En de meer filosofische: deze platforms komen uit verschillende werelden. Databricks groeide uit ML en data science, voor technische specialisten. Fabric is de end-to-end, breed toegankelijke evolutie van Microsofts bestaande dataservices, de Office-suite van dataplatforms, zo je wilt. Geen van beide is daardoor slechter. Maar organisaties passen doorgaans bij de ene cultuur beter dan bij de andere, en in mijn ervaring zegt dat meer over de uitkomst dan een benchmark.

De SAP-invalshoek, want dat is mijn dagelijks werk

Voor SAP-klanten wordt deze vergelijking deels boven onze hoofden beslist.

SAP Business Data Cloud wordt geleverd met Databricks ingebouwd, een bewust beperkte editie, waarbij veel van het ingestion- en transformatieoppervlak is uitgeschakeld. Wat betekent dat niet-SAP-workloads je nog steeds naar native Databricks duwen. Data wordt gedeeld via Delta Sharing, zonder kopiëren.

Ondertussen staat SAP BDC Connect for Microsoft Fabric gepland voor algemene beschikbaarheid in Q3 2026, bidirectioneel en zero-copy naar OneLake.

Voor een SAP-gerichte klant verschuift de vraag daarmee. Minder “Databricks of Fabric”, meer: aan welke kant van de brug bouwen we, wat blijft in BDC, en wie is eigenaar van de semantiek? Dat is sowieso een betere conversatie.

De optie die steeds van de shortlist valt

Voor klanten zonder serieuze ML-ambities en zonder de capaciteit om een platform-operationele last te dragen, is de vergelijking die we eigenlijk zouden moeten maken niet Fabric versus Databricks. Het is Fabric versus Snowflake plus Power BI plus een ELT-engine.

Er zit een eerlijke spanning in, en ik wil die benoemen: je moet voorzichtig zijn met iets in de spotlight zetten dat nog niet in je kernportfolio zit. Maar de volgorde telt. Geef eerst het eerlijke advies, los dan op wie het levert. Anders blijft kennis waar kennis naartoe gaat om te sterven: in een cursuscatalogus, zwemmen op droge grond. Het aanbieden ervan dwingt je er goed in te worden.

We hebben nog een stap te zetten op de ELT-laag in die architectuur. ADF is het voor de hand liggende eerste antwoord. Het is niet het laatste.

Wat we de komende maanden uitzoeken

Meningen zijn goedkoop, en ik heb zojuist 1.500 woorden besteed aan het bewijzen daarvan. Drie concrete vervolgstappen, gebouwd op echte opdrachten:
Een like-for-like kostenmodel. We hebben een live Databricks-omgeving. We modelleren de equivalente Fabric-architectuur ernaast en ernaast wat het verving en publiceren de methode, niet alleen het getal.

Een infrastructuurinspanningslog. Hoeveel dagen networking, identity en platformwerk voordat de eerste tabel in productie staat. Per platform. Gemeten, niet herinnerd.

Een security-pariteitslijst. Wat elk platform kan afdwingen, wat niet, en wat er kapotgaat als je private networking inschakelt.

Tot die tijd is mijn werkpositie: het SaaS versus niet-SaaS-onderscheid is het sterkste argument op tafel en het slijt. Volwassenheid pleit voor Databricks en heeft een datumstempel nodig. Power BI pleit voor Fabric en zal dat altijd doen. Al het andere zoals: kosten, schaal, lock-in, code-first, is interpretatie verkleed als feit, en dat moeten we hardop zeggen als een klant het vraagt.

Heb je echte cijfers die dit tegenspreken? Dan word ik liever gecorrigeerd dan zelfverzekerd. Stuur ze op. Ik zeg tegen een klant liever dat we iets nog niet weten en gaan uitzoeken, dan dat ik tien verschillen opdreun die niemand heeft nagekeken.

De vraag, en het grootste deel van het denken hier, kwam van mijn Powerdobs-collega’s. Ik leverde een lange rit, een stapel documentatie en eventuele resterende onzin.

Gebruikte bronnen

Altijd als eerste op de hoogte?
Volg ons op LinkedIn!

Lincedin icon

Mis geen update of event!
Abonneer je op onze nieuwsbrief en hoor als eerste over onze nieuwste updates, klantverhalen en events.

Skip form

Gerelateerde artikelen