Azure SQL Database vs. Fabric SQL Database: kosten- en rekenverschillen uitgelegd

By Mirko Peters · 2026-10-21

Vergelijk de rekenkosten, serverless schaling, capaciteitseenheden, opslagkosten en functionele afwegingen van Azure SQL Database en Fabric SQL Database.

Automatically translated with AI from the original post. Read the English original

Kiezen tussen Azure SQL Database en Fabric SQL Database komt neer op inzicht in hoe de toewijzing van rekenkracht, schaalgedrag en capaciteitseenheden verschillen. Beide draaien op dezelfde robuuste SQL-engine, maar de integratie van Fabric met OneLake en gedeelde capaciteitsmodellen brengt andere architectuur- en kostenoverwegingen met zich mee voor datagedreven organisaties.

Belangrijkste punten

• Fabric SQL Database put uit gedeelde Fabric-capaciteitseenheden (CU's) in plaats van uit zelfstandige Azure vCore-lagen.
• Rekenresources schalen terug naar nul en worden na 15 minuten inactiviteit automatisch vrijgegeven om kosten te besparen.
• Opslag wordt continu per uur gefactureerd, terwijl back-upopslag gratis is tot de omvang van je primaire database.
• Ingebouwde automatische mirroring maakt handmatige ETL-pipelines overbodig door in realtime Delta Parquet-bestanden in OneLake te vullen.
• Traditionele Azure SQL Database biedt dedicated elastic pools en SQL Server Agent-taken, die Fabric-omgevingen anders afhandelen.

Rekenkracht begrijpen: vCores vs. capaciteitseenheden

Bij het migreren van workloads of het plannen van een nieuwe cloudarchitectuur zit het fundamentele verschil tussen traditionele Azure SQL en Fabric SQL in het rekenbeheer. In een zelfstandige Azure SQL Database provisioneer je dedicated vCores of serverless compute die direct gekoppeld is aan je afzonderlijke databaseinstantie. Je beheert schaallimieten, onderhoudsvensters en prestatielagen per database.

Een Fabric SQL Database daarentegen put zijn rekenkracht uit de bredere Fabric-capaciteitspool van je organisatie. Dit gedeelde resourcemodel betekent dat je database een budget deelt met Power BI-rapporten, Data Factory-pipelines en Lakehouses. De omrekening tussen Fabric-capaciteitseenheden (CU's) en databasecapaciteit gebeurt dynamisch op de achtergrond. Een toewijzing van bijvoorbeeld 64 capaciteitseenheden komt ruwweg overeen met 24,5 vCores voor je databaseworkload. Deze gedeelde pool voorkomt de resourcefragmentatie die vaak voorkomt in omgevingen met meerdere databases, en maakt dynamisch delen mogelijk binnen je analytics-werkruimte.

Serverless schaling en regels voor facturatie bij inactiviteit

Beide databasevarianten gebruiken serverless architecturen die opschalen tijdens piekbelasting en terugschalen zodra het verkeer afneemt. De facturatie van inactieve tijd is echter bijzonder belangrijk voor budgetprognoses. Een Fabric SQL Database bewaakt de activiteit continu. Als een database volledig inactief is gedurende 15 minuten zonder binnenkomende queries, geeft hij al zijn rekenresources vrij, waardoor de rekenkosten naar nul dalen.

Om koude-startvertraging voor de volgende gebruiker te voorkomen, hanteert Microsoft een bewuste bufferperiode. Als een database twee minuten hard werkt en daarna stil wordt, betaal je voor die twee actieve minuten plus 15 extra minuten warm-standby-rekenkracht, in totaal 17 minuten. De opslag blijft echter constant en wordt elk uur gefactureerd, ongeacht of de database actief transacties verwerkt of in rust is.

Opslagkosten en back-upeconomie

Opslagbeheer in Fabric SQL Database levert aanzienlijke kostenvoordelen op ten opzichte van oudere opzetten. Doordat de database automatisch continu spiegelt naar OneLake, worden je operationele gegevens gedupliceerd naar open Delta Parquet-bestanden. Dit open formaat zorgt ervoor dat je data nooit vastzit in een propriëtaire silo: elke tool die Delta-formaat kan lezen, kan de gespiegelde kopie rechtstreeks bevragen.

Daarnaast zijn de backupkosten in het Fabric-ecosysteem sterk geoptimaliseerd. Met point-in-time restore kunnen beheerders de klok tot zeven dagen terugdraaien om te herstellen van per ongeluk beschadigde gegevens of catastrofale gebruikersfouten. De backupopslag is volledig gratis tot de totale grootte van je primaire database. Je betaalt alleen extra als de backupopslag groter wordt dan de actieve database zelf. Dat geeft een voorspelbaar financieel vangnet voor het langetermijnbewaren van gegevens.

Operationele afwegingen: wat je wint en wat je verliest

Hoewel de kern van de SQL-engine op beide platforms identiek is, vraagt de keuze voor Fabric SQL Database boven Azure SQL Database om een afweging van specifieke functionaliteit. Weten wat er in de Fabric-implementatie ontbreekt, voorkomt onverwachte architectuurproblemen tijdens de ontwikkeling.

Functies die uniek zijn voor klassieke Azure SQL

Zelfstandige Azure SQL-databases ondersteunen elastic pools native op naam, waardoor databasebeheerders granulaire controle hebben over databasegroeperingen. Ze bevatten ook de klassieke SQL Server Agent, waarop veel oudere toepassingen vertrouwen voor het intern plannen van stored procedures en onderhoudstaken.

Native voordelen van Fabric SQL

Fabric SQL bespaart je de beheerlast van het opzetten van externe replicatiepijplijnen. Zodra je de database aanmaakt, wordt spiegeling automatisch geactiveerd voor alle ondersteunde tabellen, zonder handmatige ETL-configuratie. Daarnaast integreert het native met Git voor broncodebeheer en ondersteunt het drie-delige naamgevingsconventies, zodat je operationele tabellen eenvoudig in één query kunt koppelen aan Lakehouses en Warehouses. Voor een uitgebreid overzicht van hoe deze onderdelen samenhangen, luister de volledige aflevering voor deskundige analyses en praktische strategieën voor moderne data-architecten.

Veelgestelde vragen

Hoe werkt de facturatie voor een inactieve Fabric SQL Database?

Compute-facturatie loopt door gedurende 15 minuten nadat je laatste query is uitgevoerd, zodat de database warm blijft. Daarna dalen de computekosten naar nul. Opslag wordt ongeacht de activiteit elk uur gefactureerd.

Moet ik spiegeling handmatig configureren om gegevens in OneLake te krijgen?

Nee. Spiegeling start automatisch op het moment dat je Fabric SQL Database wordt aangemaakt. Je relationele tabellen worden dan continu gesynchroniseerd naar OneLake als open Delta Parquet-bestanden, zonder eigen ETL-code.

Kan ik SQL Server Agent gebruiken om taken te plannen in een Fabric SQL Database?

SQL Server Agent is niet beschikbaar in Fabric SQL Database. Microsoft raadt in plaats daarvan aan om Data Factory-pipelines of Apache Airflow-taken te gebruiken voor planning en automatisering.

Hoe worden backups in Fabric SQL gefactureerd?

Point-in-time restore-backups zijn volledig gratis tot de totale opslaggrootte van je actieve database. Je betaalt alleen voor backupopslag als de backupomvang groter is dan de grootte van de primaire database.