News

SQL Server – Cloud Computing mit PartitionDB

📅 13. Mai 2026 ⏱ Lesezeit: 6 Minuten 🏷️ SQL Server | Hybrid Cloud | PartitionDB

Die Cloud ist kein Wunschkonzert mehr – sie ist Betriebsrealität. Doch viele Organisationen zögern: Daten in fremde Rechenzentren auslagern? Compliance-Risiken? Komplette Migration scheitert oft an Altlasten, regulatorischen Hürden oder schlicht am Mut der Entscheider. Der pragmatische Weg heißt Hybrid Cloud: operative Daten bleiben on‑premise, während Archive, Historien oder Zusatzdaten in die Cloud wandern. Doch wie setzt man eine solche Verteilung technisch um, ohne die Anwendung umzuschreiben? Eine Antwort heißt PartitionDB. Dieser Artikel zeigt, wie PartitionDB SQL Server in eine hybride Cloud-Landschaft überführt – transparent, verteilt und dennoch vertraut.

🎯 Die Herausforderung: Cloud-Migration ohne Bruch

Klassische Ansätze scheitern oft an der Komplexität. Datenbank-Sharding oder manuell verteilte Abfragen erfordern tiefe Eingriffe in den Anwendungscode. Genau hier setzt PartitionDB an. Die Plattform virtualisiert mehrere Datenbanken zu einer logischen Einheit – unabhängig davon, ob die Partitionen on‑premise, in der Cloud oder hybrid betrieben werden. Das Ergebnis: Sie arbeiten „wie bisher“ – mit denselben SQL-Abfragen, denselben Tools, demselben Code – während die Daten physisch verteilt sind.

📌 Definition: PartitionDB ist eine „robuste Virtualisierungs-Plattform für verteiltes Datenbankmanagement“, die Organisationen eine mehrschichtige Datenbankarchitektur in Multi-Tenancy-Umgebungen ermöglicht und gleichzeitig eine schrittweise, transparente Cloud-Migration erlaubt.

🏗️ Die Architektur: Gate, Partitionen und transparente Verteilung

Das Herzstück von PartitionDB ist die sogenannte Gate. Die Gate ist eine Steuerungsebene, die als separate Datenbank oder direkt in die bestehende On‑Premise-Datenbank integriert werden kann. Sie verwaltet alle Verteilungsregeln: Welche Tabelle liegt wo? Welche Partition ist in der Cloud, welche bleibt lokal? Für die Anwendung bleibt alles transparent – sie kommuniziert nur mit der Gate, die ihrerseits die Anfragen an die richtigen Partitionen weiterleitet.

Besonders elegant: PartitionDB unterstützt eine Shared‑Nothing‑Architektur auf Basis von partitionierten Datenbanken. Dadurch werden Transaktionen auf eine Partition beschränkt – ein komplexer Zwei‑Phasen‑Commit wird vermieden, was die Performance massiv verbessert.

🧩 Multi-Tenancy und hybride Szenarien

PartitionDB glänzt besonders in Multi‑Tenancy‑Umgebungen. Jeder Mandant kann seine eigene Partition erhalten – isoliert, sicher und individuell skalierbar. Die Plattform verwaltet die Verteilung der Last, des Concurrency‑Controllings und der Pufferung effizient über mehrere Datenbanken hinweg. Unternehmen können Schritt für Schritt in die Cloud wachsen: Zuerst wandern nur nicht‑operative Daten (z. B. Logs, historische Bestellungen), später folgen weitere Teile. Der Wechsel ist für Endanwender unsichtbar.

❌ ANTI-PATTERN: Die „Big Bang“‑Migration Viele Teams versuchen, die gesamte Datenbank auf einmal in die Cloud zu verschieben – mit oft katastrophalen Folgen: Performance‑Einbrüche, Compliance‑Verstöße, lange Ausfallzeiten. Statt eines großen Risikos setzt man besser auf eine schrittweise Verteilung. PartitionDB ermöglicht genau das: Tabellen, Stored Procedures oder Views können einzeln und ohne Code‑Änderungen in die Cloud verschoben werden.

✅ BESSER: Schrittweise Verteilung mit PartitionDB Beginnen Sie mit einer nicht‑kritischen Tabelle (z. B. einer Audit‑ oder Logging‑Tabelle) und verlagern Sie diese in die Cloud. Prüfen Sie das Verhalten. Wenn alles stabil läuft, folgen weitere Objekte. So migrieren Sie risikofrei und sammeln wertvolle Erfahrungen mit der hybriden Architektur.

📦 Praxisbeispiel: On‑Premise + Cloud im Verbund

Das folgende vereinfachte Beispiel illustriert die Arbeitsweise:

Ausgangslage: Eine On‑Premise‑Datenbank NorthStar enthält operative Kundendaten.
Gate erstellen: CREATE GATE ... – die Steuerungsinstanz wird in der On‑Premise‑DB angelegt.
Cloud‑Datenbank anlegen: Eine zweite Datenbank NorthStarCloud wird in Azure (oder einem beliebigen Cloud‑Anbieter) erstellt und mit der Gate verbunden.
Tabelle verlagern: Mit einem Befehl wie EXEC PdbtargetSplitTable 'NorthStar', 'dbo', 'CustomerLogins', 'NorthStarCloud'; wird die Tabelle CustomerLogins ohne Datenverlust und ohne Änderung der Anwendung in die Cloud verschoben.
Weiterarbeiten: Die Anwendung kann nun Joins über On‑Premise‑ und Cloud‑Tabellen ausführen, als wären sie in einer einzigen Datenbank – die Gate kümmert sich um die verteilte Abfrage.

Dieses Vorgehen lässt sich auf jedes Datenbankobjekt anwenden: Tabellen, Stored Procedures, Views – alles kann nach und nach in die Cloud wandern.

⚖️ PartitionDB im Vergleich zu nativen Azure-Optionen

Kriterium	PartitionDB	Azure SQL Hyperscale / Managed Instance
Transparente Verteilung	Ja – Anwendung sieht eine logische DB	Nein – Partitionierung bleibt sichtbar (Filegroups, keine unabhängigen Knoten)
Hybridbetrieb (on‑premise + Cloud)	Native Unterstützung, nahtlos	Nur eingeschränkt (z. B. über Data Sync)
Sharding / horizontale Skalierung	Ja, über virtuelle Partitionen	Erfordert Elastic Pools + manuelles Sharding
Multi-Tenancy-Fähigkeiten	Eigenes Konzept für Mandantenisolierung	Erfordert separates Schema je Mandant
Vendor Lock‑in	Gering (kann mit verschiedenen Clouds arbeiten)	Hoch (Azure‑spezifisch)
Lizenzkosten	Zusätzliche Lizenz	Azure‑Verbrauchspreis + SQL Server‑Lizenz bei BYOL

📌 Wichtig zu verstehen: Die native Partitionierung in SQL Server und Azure SQL teilt Daten lediglich in Dateigruppen innerhalb einer Instanz – sie schafft keine unabhängigen, verteilten Knoten. Für echte horizontale Verteilung über Maschinengrenzen hinweg benötigt man entweder eine Middleware wie PartitionDB oder muss auf manuelles Sharding auf Applikationsebene setzen.

⚠️ Herausforderungen und Überlegungen

PartitionDB bringt nicht nur Vorteile, sondern auch neue Anforderungen mit sich:

Hochverfügbarkeit & Always On: Die Kombination von PartitionDB mit SQL Server Always On Availability Groups ist nicht trivial, da die Gate die Verteilung steuert. Hier sind eigene Backup‑Mechanismen (BackupDB) verfügbar, die aber nicht alle Cluster‑Anforderungen erfüllen. Wer 24/7‑Verfügbarkeit benötigt, muss zusätzliche Maßnahmen ergreifen.
Cross‑Partition‑Queries: Obwohl verteilte Joins möglich sind, können sie bei großen Datenmengen Performance‑Engpässe verursachen. Eine durchdachte Partitionierungsstrategie ist essenziell.
Reife & Community: PartitionDB ist ein spezialisiertes Produkt einer kleinen Firma (gegründet 2015 in Israel, 2 Mitarbeiter). Der Support und die Weiterentwicklung hängen stark vom Anbieter ab – anders als bei den riesigen Ökosystemen von Microsoft, AWS oder Google.

✅ Fazit: Für wen lohnt sich PartitionDB?

➤ Organisationen, die schrittweise in die Cloud migrieren möchten, ohne ihre Anwendung umzustellen.
➤ Multi‑Tenancy‑SaaS‑Anbieter, die Mandanten isolieren und individuell skalieren müssen.
➤ Unternehmen mit Compliance‑Anforderungen, die bestimmte Daten zwingend on‑premise belassen müssen, aber trotzdem Cloud‑Vorteile nutzen wollen.
➤ Teams, die eine kostenkontrollierte Hybrid‑Cloud aufbauen und kein vollständiges Redesign ihrer Datenbankarchitektur durchführen möchten.

Einschränkungen: Wer hohe Anforderungen an 24/7‑Verfügbarkeit und vollständige Always On‑Integration hat, sollte die zusätzlichen Backup‑ und Failover‑Mechanismen genau prüfen. Für reine Cloud‑Native‑Anwendungen ohne Hybrid‑Zwang sind native Azure‑Lösungen oft die einfachere Wahl.