Microsoft Fabric · 15 juni 2026 · 6 min
Microsoft Fabric: waarom capaciteitskosten het echte architectuurvraagstuk zijn
Fabric-trajecten stranden zelden op techniek. Ze stranden op capaciteitskosten die niemand vooraf heeft doordacht. Drie ontwerpkeuzes die het verschil maken.
Microsoft Fabric bundelt data engineering, warehousing en BI in één platform met één capaciteitsmodel. Dat is de kracht, maar ook het risico. Waar organisaties voorheen per werklast betaalden, betaalt men nu voor gedeelde capaciteit die door alle werklasten wordt geconsumeerd. Eén slecht ontworpen pipeline kan de rapportages van een hele afdeling vertragen én de kosten opdrijven.
Capaciteit is een architectuurbeslissing
De vraag 'welke capaciteit hebben wij nodig' is niet te beantwoorden zonder architectuurkeuzes: welke werklasten draaien op welke capaciteit, hoe worden ontwikkeling en productie gescheiden, en welke teams krijgen welke ruimte. Organisaties die dit overslaan, ontdekken de gevolgen pas op de eerste factuur na livegang.
Drie ontwerpkeuzes die vooraf moeten
Eén: scheid capaciteiten naar werklastprofiel, niet naar organisatiestructuur. Twee: richt monitoring op capaciteitsconsumptie in vanaf dag één, niet als nazorg. Drie: leg vast wie mag opschalen en op basis waarvan; anders wordt opschalen de standaardreactie op elk prestatieprobleem.
Wie Fabric beoordeelt, moet dus niet alleen naar functionaliteit kijken maar naar het kostenmodel onder productie-omstandigheden. Een onafhankelijke doorrekening vooraf kost een fractie van wat ongecontroleerde capaciteitsgroei achteraf kost.