SQL Server database in Microsoft Fabric

Microsoft Fabric is een geïntegreerd platform dat data-analyse, opslag en verwerking combineert en heeft nu ook SQL-database hieraan aan toegevoegd. Momenteel nog wel beschikbaar als preview. Deze ontwikkeling biedt nieuwe mogelijkheden voor organisaties die vertrouwd zijn met SQL Server, maar wat zijn de verschillen met de andere opslag opties in Fabric zoals Lakehouse en Warehouse? En waarom zou ik kiezen voor een SQL Server in Fabric in plaats van een Azure database? Daar gaan we in deze blog wat dieper op in.

Wat is de SQL-database in Microsoft Fabric?
De SQL-database in Fabric is een doorontwikkelde versie van Azure SQL-database, nu geïntegreerd in het Fabric-platform. Het is een eenvoudig aan te maken en te beheren database die goed samenwerkt met andere Fabric-onderdelen en draait op dezelfde SQL Database Engine als Azure SQL-database. Microsoft voorspelt een enorme toename van de ontwikkeling van Apps door AI. Microsoft speelt hierop in door de Copilot integratie en de GraphQL API integratie voor Fabric SQL Server.

Automatische OneLake integratie
Een andere belangrijke use case zijn de analytics mogelijkheden die de Fabric SQL-database biedt. Dit wordt bewerkstelligd door de automatische replicatie naar Onelake. Bij het aanmaken van een SQL-database wordt automatisch een Lakehouse item aangemaakt en een default Semantic model. Vanuit Power BI perspectief is er dan een Direct Lake connectie in je Semantic model wat data duplicatie voorkomt t.o.v. de klassieke import modus en extra doorlooptijd beperkt.

De OneLake integratie biedt ook mogelijkheden voor Machine Learning en Data Sciene vraagstukken door bijvoorbeeld gebruik te maken van Notebooks en Spark of Python engines. Binnen een Fabric omgeving kan je meerdere Lake House, Warehouse of SQL-database items hebben, maar het voordeel is dat je queries kan schrijven over gecombineerde items.

Data verwerking
Om de data in je Fabric SQL-database te krijgen zijn er meerdere mogelijkheden. Zo kan je Fabric Pipelines (vergelijkbaar met Azure Data Factory) gebruiken en met bijvoorbeeld een Copy activiteit (zie plaatje hieronder) je database vullen vanuit een willekeurige bron. Je kan Notebooks gebruiken om daar je code te schrijven voor dataverwerking of je kan database Mirroring gebruiken. Dit laatste is ook een vrij nieuwe optie en wordt ondersteund voor een paar database smaken waaronder Azure. Interessant als je geen queries mag draaien op de applicatie database of als je meer analytics mogelijkheden wil bieden dan alleen een Semantic model met import modus. Door Mirroring en automatische Onelake replicatie is de data dan ook nog eens Near-RealTime.

Azure SQL-database vs Fabric SQL-database
Wanneer Ms Fabric al beschikbaar is in je organisatie dan kan je gebruik maken van de Fabric SQL-database zonder extra licentie kosten. Tenminste dat is nu nog zo in de preview periode, maar waarschijnlijk zal straks wel extra betaald moeten worden voor automatische database back-up al zal dat waarschijnlijk een stuk goedkoper zijn dan een Azure licentie. Al is de vraag of back-up functionaliteit wel altijd nodig is als je data vanuit de bron weer kan repliceren en voor ontwikkel en test werkzaamheden kan je een aparte database aanmaken en gebruik maken van Deploy pipelines of GIT Integration. Wel is het zo dat een Fabric SQL-database net als andere items in Fabric capaciteit units verbruiken, dus kijk goed of dit nog past en voer eventueel een analyse uit met de Microsoft Fabric Capacity Metrics-app. De performance is afhankelijk van de grootte van de capaciteit. Grofweg komt 1 CU overeen met 100 DTU van een Azure SQL-database. Los van de kosten kunnen we nog het volgende onderscheid maken tussen Fabric SQL-database en Azure Database.

Verschil Fabric Lakehouse en Warehouse
Er is zeker een bepaalde overlap tussen de verschillende opslagmogelijkheden in Fabric, maar er zijn ook verschillen. Vanuit praktijkervaring zijn er onder andere een aantal zaken die je net anders moet oplossen in Lakehouse en Warehouse. Zo kan je bijvoorbeeld niet rechtstreeks in een pipeline via een bron naar een Warehouse, maar moet je eerst de data laden in Lakehouse. Primairy Keys definiëren en SQL Merge statements zijn niet mogelijk en ook kan sommige SQL-code op een Lakehouse alleen via een notebook uitgevoerd worden. Als we de diverse opslagopties binnen Fabric analyseren, kunnen we op hoofdlijnen de volgende toepassingsmogelijkheden identificeren.

Fabric SQL Database → Voor kleine tot middelgrote datasets (max 4 TB). Voor analisten en BI-teams met SQL-kennis die zowel Power BI rapportages als dataopslag en verwerking in 1 cloud platform willen toepassen voor structured data.
Warehouse → Voor grote datasets en BI-rapportages, geschikt voor data engineers en analytische teams die vooral SQL kennis hebben en met structered en semi-structered data aan de slag gaan, maar ook de mogelijkheid willen hebben om met Spark te werken.
Lakehouse → Voor big data, machine learning en AI, voor data science en engineering-expers met Spark kennis die zowel met structered als unstructered data verwerking aan de slag willen.

Voor de meer technische verschillen Microsoft heeft op deze site ook een tabel staan met de vergelijking tussen Lakehouse, Warehouse, Eventhouse, SQL-database en Power BI Datamart. De laatste optie Power BI Datamart in deze vergelijkingstabel zou ik overigens negeren, want die is al een paar jaar in preview en zal waarschijnlijk nooit de productie status halen door de opkomst van de andere opslagmogelijkheden.

Conclusie
De introductie van de SQL-database in Microsoft Fabric biedt organisaties een bewezen database binnen een geïntegreerd platform die eenvoudig aan te maken is en waar amper beheer op nodig is. Door de juiste keuze te maken tussen een Lakehouse, Warehouse of SQL-database in Fabric of een mix hiervan, gebaseerd op specifieke behoeften en datatypes, kunnen organisaties hun data-infrastructuur verder optimaliseren en meer waarden halen uit hun data platform en rapportagesysteem.