Azure SQL Database vs. Fabric SQL Database: Unterschiede bei Kosten und Rechenleistung im Detail

Von Mirko Peters · 2026-10-21

Vergleichen Sie die Rechenkosten, das serverlose Skalieren, die Kapazitätseinheiten, die Speicherkosten und die funktionalen Kompromisse von Azure SQL Database und Fabric SQL Database.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Die Wahl zwischen Azure SQL Database und Fabric SQL Database hängt davon ab, wie sich Rechenzuweisung, Skalierungsverhalten und Kapazitätseinheiten unterscheiden. Beide basieren auf derselben leistungsstarken SQL-Engine. Die Integration von Fabric in OneLake und das gemeinsame Kapazitätsmodell bringen für datengetriebene Organisationen jedoch eigene architektonische und kostenseitige Überlegungen mit sich.

Das Wichtigste in Kürze

• Fabric SQL Database nutzt gemeinsame Fabric-Kapazitätseinheiten (CUs) statt eigenständiger Azure-vCore-Stufen.
• Rechenressourcen werden nach 15 Minuten Inaktivität auf null herunterskaliert und automatisch freigegeben, um Kosten zu sparen.
• Der Speicher wird laufend stündlich abgerechnet, während die Sicherungsspeicherung bis zur Größe Ihrer primären Datenbank kostenlos ist.
• Die integrierte automatische Spiegelung macht manuelle ETL-Pipelines überflüssig, indem sie Delta-Parquet-Dateien in Echtzeit in OneLake bereitstellt.
• Die klassische Azure SQL Database bietet dedizierte elastische Pools und SQL-Server-Agent-Aufträge, die in Fabric-Umgebungen anders gehandhabt werden.

Rechenleistung verstehen: vCores vs. Kapazitätseinheiten

Bei der Migration von Workloads oder der Planung einer neuen Cloud-Architektur liegt der grundlegende Unterschied zwischen klassischer Azure SQL und Fabric SQL in der Verwaltung der Rechenleistung. In einer eigenständigen Azure SQL Database stellen Sie dedizierte vCores oder serverlose Rechenleistung bereit, die direkt mit Ihrer einzelnen Datenbankinstanz verknüpft ist. Skalierungsgrenzen, Wartungsfenster und Leistungsstufen verwalten Sie pro Datenbank.

Eine Fabric SQL Database hingegen bezieht ihre Rechenleistung aus dem gemeinsamen Fabric-Kapazitätspool Ihrer Organisation. Dieses gemeinsame Ressourcenmodell bedeutet, dass sich Ihre Datenbank ein Budget mit Power-BI-Berichten, Data-Factory-Pipelines und Lakehouses teilt. Die Umrechnung zwischen Fabric-Kapazitätseinheiten (CUs) und Datenbankleistung erfolgt dynamisch im Hintergrund. Eine Zuweisung von 64 Kapazitätseinheiten entspricht beispielsweise etwa 24,5 vCores für Ihre Datenbank-Workload. Dieser einheitliche Poolansatz verhindert die Ressourcenzersplitterung, die in Umgebungen mit mehreren Datenbanken häufig auftritt, und ermöglicht dynamische Nutzung über Ihren Analytics-Arbeitsbereich hinweg.

Serverloses Skalieren und Regeln für die Abrechnung im Leerlauf

Beide Datenbankangebote nutzen serverlose Architekturen, die bei Spitzenlast in Abfragen hochskalieren und bei nachlassendem Datenverkehr wieder herunterskalieren. Für die Budgetplanung ist die Abrechnung von Leerlaufzeiten jedoch besonders wichtig. Eine Fabric SQL Database überwacht die Aktivität laufend. Ist eine Datenbank 15 Minuten lang vollständig ohne eingehende Abfragen inaktiv, gibt sie alle Rechenressourcen frei, sodass die Rechenkosten auf null sinken.

Damit der nächste Nutzer keine Kaltstart-Latenz erlebt, setzt Microsoft bewusst einen Pufferzeitraum ein. Wenn eine Datenbank zwei Minuten lang intensiv arbeitet und danach ruhig wird, werden Ihnen diese zwei aktiven Minuten plus 15 zusätzliche Minuten für die betriebsbereite Rechenleistung berechnet, insgesamt also 17 Minuten. Der Speicher bleibt hingegen unverändert und wird stündlich abgerechnet, unabhängig davon, ob die Datenbank gerade Transaktionen verarbeitet oder ruht.

Speicherkosten und Sicherungswirtschaft

Die Speicherverwaltung in Fabric SQL Database bringt im Vergleich zu herkömmlichen Setups deutliche Kostenvorteile. Da die Datenbank automatisch eine kontinuierliche Spiegelung nach OneLake startet, werden Ihre Betriebsdaten in offene Delta-Parquet-Dateien repliziert. Dieses offene Format sorgt dafür, dass Ihre Daten nie an ein proprietäres Silo gebunden sind. Jedes Tool, das das Delta-Format lesen kann, kann die gespiegelte Kopie direkt abfragen.

Darüber hinaus ist die Backup-Wirtschaftlichkeit im Fabric-Ökosystem stark optimiert. Mit der Point-in-time-Wiederherstellung können Administratoren die Zeit um bis zu sieben Tage zurückdrehen, um sich von versehentlicher Datenbeschädigung oder schwerwiegenden Benutzerfehlern zu erholen. Der Backup-Speicher ist bis zur Gesamtgröße Ihrer primären Datenbank vollständig kostenlos. Zusätzliche Kosten entstehen erst, wenn der Backup-Speicher größer wird als die aktive Datenbank selbst. So erhalten Sie ein planbares finanzielles Sicherheitsnetz für die langfristige Datenaufbewahrung.

Betriebliche Kompromisse: Was Sie gewinnen und was Sie verlieren

Obwohl die zentrale SQL-Engine auf beiden Plattformen identisch ist, erfordert die Wahl von Fabric SQL Database gegenüber Azure SQL Database die Abwägung bestimmter Funktionsunterschiede. Wer weiß, was in der Fabric-Implementierung fehlt, vermeidet unerwartete architektonische Hürden während der Entwicklung.

Funktionen, die nur in klassischem Azure SQL verfügbar sind

Eigenständige Azure-SQL-Datenbanken unterstützen elastische Pools nativ über den Namen und ermöglichen Datenbankadministratoren so eine detaillierte Steuerung der Datenbankgruppierungen. Außerdem enthalten sie den klassischen SQL Server Agent, auf den sich viele Altanwendungen intern verlassen, um gespeicherte Prozeduren und Wartungsaufgaben zu planen.

Native Vorteile von Fabric SQL

Fabric SQL macht den administrativen Aufwand für die Einrichtung externer Replikationspipelines überflüssig. Sobald Sie die Datenbank erstellen, wird die Spiegelung für alle unterstützten Tabellen automatisch aktiviert, ohne manuelle ETL-Konfiguration. Zudem ist die Integration mit Git für die Quellcodeverwaltung nativ vorhanden, und es werden dreiteilige Namenskonventionen unterstützt. So können Sie operative Tabellen problemlos in einer einzigen Abfrage mit Lakehouses und Warehouses verknüpfen. Einen umfassenden Überblick darüber, wie diese Komponenten zusammenspielen, bietet die vollständige Episode, in der Experten fundierte Analysen und praxisnahe Strategien für moderne Data Architects vorstellen.

Häufige Fragen

Wie funktioniert die Abrechnung für eine inaktive Fabric SQL Database?

Die Rechenleistung wird noch 15 Minuten nach Abschluss Ihrer letzten Abfrage berechnet, damit die Datenbank betriebsbereit bleibt. Danach sinken die Rechenkosten auf null. Die Speicherkosten werden unabhängig von der Aktivität stündlich abgerechnet.

Muss ich die Spiegelung manuell konfigurieren, damit Daten in OneLake gelangen?

Nein. Die Spiegelung startet automatisch, sobald Ihre Fabric SQL Database erstellt wird. Dabei synchronisiert sie Ihre relationalen Tabellen kontinuierlich als offene Delta-Parquet-Dateien nach OneLake, ohne eigenen ETL-Code.

Kann ich den SQL Server Agent in einer Fabric SQL Database zur Auftragsplanung verwenden?

Der SQL Server Agent ist in Fabric SQL Database nicht verfügbar. Microsoft empfiehlt stattdessen, für Planung und Automatisierung Data-Factory-Pipelines oder Apache-Airflow-Aufträge zu verwenden.

Wie werden Backups in Fabric SQL abgerechnet?

Point-in-time-Wiederherstellungs-Backups sind bis zur Gesamtgröße des aktiven Datenbankspeichers vollständig kostenlos. Sie zahlen nur dann für den Backup-Speicher, wenn der Umfang Ihrer Backups die Größe der primären Datenbank übersteigt.