Für kleine Unternehmen ist meist eine verwaltete Cloud-Datenbank sinnvoller als ein selbst betriebener Datenbankserver. Der Cloud-Anbieter übernimmt dabei unter anderem die technische Plattform, Wartungsfunktionen und automatisierte Sicherungsmechanismen; das Unternehmen bleibt jedoch für Datenmodell, Benutzerrechte, Anwendungen und Kostenkontrolle verantwortlich. In einer Microsoft-geprägten Umgebung ist Azure SQL Database häufig der naheliegende Ausgangspunkt. Für neue, herstellerunabhängig entwickelte Anwendungen ist ein verwaltetes PostgreSQL-Angebot oft flexibler, während Microsoft Dataverse vor allem zu Power Apps und anderen Werkzeugen der Power Platform passt.
Ein universeller Sieger lässt sich nicht seriös bestimmen. Die passende Wahl hängt davon ab, ob eine bestehende SQL-Server-Anwendung umziehen soll, eine neue Webanwendung entsteht oder Fachabteilungen ohne klassische Softwareentwicklung Prozesse abbilden möchten. Vor einem Vertragsabschluss sollten außerdem Datenmenge, Zugriffsverhalten, Wiederherstellungsbedarf, Standortanforderungen und monatliches Kostenlimit feststehen.
Die erste Trennung: Datenbankdienst oder fertige Arbeitsplattform
Unter dem Begriff Cloud-Datenbank werden technisch unterschiedliche Angebote zusammengefasst. Ein verwalteter relationaler Datenbankdienst stellt eine SQL-Datenbank bereit, auf die eine Anwendung über einen Datenbanktreiber oder eine Programmierschnittstelle zugreift. Azure SQL Database, Amazon RDS und Google Cloud SQL gehören in diese Gruppe. Sie eignen sich für Warenwirtschaft, Kundenportale, individuelle Fachanwendungen, Schnittstellen und andere Systeme mit einem strukturierten Datenmodell.
Microsoft Dataverse liegt auf einer anderen Ebene. Es ist eine Datenplattform für die Power Platform und stellt Tabellen, Beziehungen, Rollen sowie Geschäftslogik für Power Apps und Automatisierungen bereit. Dataverse ist nicht einfach ein austauschbarer SQL-Server, auf den jede vorhandene Desktop-Anwendung unverändert zugreifen kann. Die Lösung ist interessant, wenn Prozesse ohnehin mit Power Apps, Power Automate oder Dynamics-Umgebungen umgesetzt werden sollen.
Auch eine online gespeicherte Excel-Datei oder eine SharePoint-Liste ist nicht automatisch eine Cloud-Datenbank. Solche Werkzeuge können kleine Listen und einfache Teamabläufe abdecken. Sobald mehrere Anwendungen gleichzeitig schreiben, Beziehungen zwischen vielen Datensätzen benötigt werden oder Transaktionen zuverlässig verarbeitet werden müssen, ist eine echte Datenbank die belastbarere Grundlage.
Vier Lösungswege nach demselben Raster
Für eine faire Auswahl müssen alle Kandidaten nach denselben Punkten beurteilt werden: unterstütztes Datenbanksystem, Microsoft-Integration, Verwaltungsaufwand, Bindung an die Plattform, Kostenmodell und typischer Einsatz. Die Preise selbst verändern sich nach Region, Leistungsklasse, Speicher, Sicherungsaufbewahrung und Zusatzfunktionen. Eine pauschale Monatszahl wäre ohne festgelegte Konfiguration nicht aussagekräftig.
Azure SQL Database: passend für SQL Server und Microsoft-Umgebungen
Azure SQL Database ist ein verwalteter relationaler Dienst auf Basis der SQL-Server-Technologie. Die Lösung bietet sich an, wenn eine Anwendung bereits mit Microsoft SQL Server arbeitet oder das Unternehmen Identitäten und Zugriffe eng mit Microsoft Azure beziehungsweise Microsoft Entra ID verbinden möchte. Windows-Programme können über passende SQL-Treiber zugreifen; Microsoft 365 allein macht eine Anwendung jedoch noch nicht kompatibel.
- Datenbanksystem: SQL-Server-basierte relationale Datenbank.
- Microsoft-Integration: stark, besonders bei Microsoft Entra ID, Azure-Anwendungen und Microsoft-Entwicklungswerkzeugen.
- Verwaltungsaufwand: geringer als bei einer selbst installierten SQL-Server-Instanz, aber Datenmodell, Abfragen und Berechtigungen bleiben eigene Aufgaben.
- Plattformbindung: höher, wenn anwendungsspezifische SQL-Server-Funktionen intensiv genutzt werden.
- Kostenmodell: abhängig von gewähltem Leistungsmodell, Rechenleistung, Speicher, Sicherungen und möglichen Zusatzdiensten.
- Typischer Einsatz: bestehende Microsoft-Anwendung, interne Fachsoftware oder neue Anwendung im Azure-Umfeld.
Eine vorhandene SQL-Server-Datenbank lässt sich nicht allein aufgrund des Produktnamens ohne Prüfung verschieben. SQL Server auf einem eigenen Rechner kann Funktionen enthalten, die in einem verwalteten Einzeldatenbankdienst anders bereitgestellt werden oder eine andere Azure-Betriebsform erfordern. Vor der Migration müssen daher Schema, Anmeldeverfahren, geplante Aufträge, anwendungsübergreifende Abfragen und verwendete Serverfunktionen inventarisiert werden.
Azure Database for PostgreSQL: offenere Technik innerhalb von Azure
Azure Database for PostgreSQL verbindet das verbreitete Open-Source-Datenbanksystem PostgreSQL mit der Verwaltung über Azure. Diese Variante ist interessant, wenn eine neue Anwendung entstehen soll, das Entwicklerteam PostgreSQL beherrscht und andere Azure-Dienste genutzt werden. Gegenüber Azure SQL Database ist die Datenbanktechnik weniger eng an SQL Server gebunden, die gewählte Cloud-Architektur kann dennoch Abhängigkeiten von Azure-Funktionen schaffen.
- Datenbanksystem: PostgreSQL.
- Microsoft-Integration: gut auf Infrastruktur- und Identitätsebene, aber nicht mit SQL-Server-Kompatibilität gleichzusetzen.
- Verwaltungsaufwand: Betriebssystem und grundlegende Dienstverwaltung liegen beim Anbieter; Abfragen, Erweiterungen, Rollen und Leistungsanalyse bleiben relevant.
- Plattformbindung: beim Datenbanksystem vergleichsweise begrenzt, bei ergänzenden Azure-Diensten möglicherweise höher.
- Kostenmodell: abhängig von Rechenleistung, Speicher, Sicherung, Datenübertragung und gewählter Ausfallsicherheit.
- Typischer Einsatz: neue Web- oder Geschäftsanwendung mit PostgreSQL in einer Azure-Umgebung.
Diese Wahl ist nicht automatisch besser als Azure SQL Database. Eine Anwendung, die T-SQL, SQL-Server-Treiber oder spezielle SQL-Server-Eigenschaften erwartet, müsste für PostgreSQL wahrscheinlich angepasst werden. Für eine Neuentwicklung kann PostgreSQL dagegen den späteren Wechsel zwischen Betriebsumgebungen erleichtern, sofern die Anwendung keine proprietären Cloud-Funktionen voraussetzt.
Amazon RDS: sinnvoll bei Anwendungen im AWS-Umfeld
Amazon Relational Database Service, kurz Amazon RDS, verwaltet relationale Datenbanken mit mehreren unterstützten Datenbank-Engines. Dazu zählen verbreitete Systeme wie PostgreSQL, MySQL und SQL Server, wobei Funktionen und Lizenzbedingungen je nach Engine und Konfiguration abweichen. RDS passt vor allem dann, wenn Anwendung, Speicher und weitere Dienste bereits in AWS betrieben werden.
- Datenbanksystem: mehrere wählbare relationale Engines.
- Microsoft-Integration: SQL Server kann je nach angebotener Variante verfügbar sein; die übergreifende Verwaltung bleibt jedoch AWS-zentriert.
- Verwaltungsaufwand: geringer als bei einer Datenbank auf einer eigenen virtuellen Maschine, aber Engine-Updates und Anwendungskompatibilität müssen geplant werden.
- Plattformbindung: von der Engine und der Nutzung zusätzlicher AWS-Dienste abhängig.
- Kostenmodell: geprägt durch Instanzklasse, Laufzeit, Speicher, Sicherungen, Datenübertragung und gegebenenfalls Datenbanklizenzen.
- Typischer Einsatz: relationale Datenbank für eine Anwendung, deren übrige Infrastruktur in AWS liegt.
Für ein kleines Unternehmen mit ausschließlich Windows-PCs und Microsoft 365 entsteht aus RDS allein kein unmittelbarer Vorteil. Der Standort der Benutzergeräte entscheidet weniger als der Standort der Anwendung. Läuft die Geschäftsanwendung in AWS, verkürzt eine Datenbank in derselben Plattform typischerweise den technischen Weg und vereinfacht die gemeinsame Verwaltung. Eine Datenbank in einer anderen Cloud kann zusätzliche Netzwerk-, Sicherheits- und Kostenfragen erzeugen.
Google Cloud SQL: verwaltete SQL-Engines in Google Cloud
Google Cloud SQL stellt verwaltete relationale Datenbanken für unterstützte Engines wie PostgreSQL, MySQL und SQL Server bereit. Die Lösung ist eine passende Kandidatin, wenn eine Anwendung bereits auf Google Cloud läuft oder ein Entwicklungspartner diese Plattform betreut. Windows-Anwendungen können technisch auf eine dort erreichbare Datenbank zugreifen, sofern Treiber, Netzwerkfreigaben und Authentifizierung zusammenpassen.
- Datenbanksystem: mehrere unterstützte SQL-Engines.
- Microsoft-Integration: über Datenbanktreiber und Anwendungsanbindung möglich, aber weniger Microsoft-zentriert als Azure.
- Verwaltungsaufwand: grundlegende Infrastrukturaufgaben übernimmt der Dienst; Datenbankoptimierung und Rechtekonzept bleiben beim Betreiber.
- Plattformbindung: bei Standard-PostgreSQL oder MySQL geringer als bei intensiver Nutzung ergänzender Google-Cloud-Dienste.
- Kostenmodell: abhängig von Maschine, Speicher, Sicherungen, Netzwerk und Ausfallsicherheitsoptionen.
- Typischer Einsatz: relationale Datenbank für Anwendungen innerhalb von Google Cloud.
Cloud SQL sollte nicht nur wegen einer vertrauten Bürosoftware von Google gewählt werden. Die Datenbankentscheidung folgt in erster Linie der Anwendungsarchitektur, dem Wissen des technischen Dienstleisters und den Betriebsanforderungen. Office-Dateien lassen sich auch mit Anwendungen verbinden, deren Datenbank in Google Cloud liegt; dadurch entsteht aber keine native Office-Datenbank.
Microsoft Dataverse: für Power Apps statt freier Serveranbindung
- Datenbanksystem: verwaltete Datenplattform mit eigenem Anwendungs- und Sicherheitsmodell.
- Microsoft-Integration: besonders eng mit Power Platform und darauf aufbauenden Lösungen.
- Verwaltungsaufwand: wenig klassische Serveradministration, dafür Plattformverwaltung, Umgebungen, Rollen und Lösungsmanagement.
- Plattformbindung: hoch, weil Datenmodell und Anwendungen eng mit der Power Platform verbunden sein können.
- Kostenmodell: von benötigten Microsoft-Lizenzen, Kapazitäten und eingesetzten Anwendungen abhängig.
- Typischer Einsatz: interne Formulare, Genehmigungen und Geschäftsprozesse auf Basis der Power Platform.
Vor der Auswahl muss im Microsoft-Administrationsbereich geprüft werden, welche Lizenzen und Dataverse-Kapazitäten für die vorgesehenen Benutzer und Anwendungen tatsächlich gelten. Eine vorhandene Microsoft-365-Lizenz bedeutet nicht automatisch, dass jeder geplante Dataverse- und Power-Apps-Anwendungsfall vollständig abgedeckt ist.
Die Auswahl in fünf Entscheidungszweigen
- Eine vorhandene SQL-Server-Anwendung soll umziehen: Prüfe zuerst Azure SQL Database und verwaltete SQL-Server-Angebote der Cloud, in der die Anwendung betrieben wird. Lasse vorab ermitteln, welche SQL-Server-Funktionen, Anmeldungen und Hintergrundaufgaben die Software verwendet.
- Eine neue Webanwendung wird entwickelt: PostgreSQL ist häufig eine gut übertragbare Ausgangsbasis. Wähle Azure Database for PostgreSQL, Amazon RDS oder Google Cloud SQL danach aus, wo die Anwendung läuft und welches System das betreuende Team sicher administrieren kann.
- Interne Abläufe sollen mit Power Apps entstehen: Prüfe Dataverse, wenn Rollen, Formulare und Automatisierungen innerhalb der Power Platform benötigt werden. Besteht bereits eine externe SQL-Datenbank, muss nicht jeder Prozess zwangsläufig nach Dataverse verlagert werden.
- Es gibt keine eigene IT-Abteilung: Bevorzuge einen vollständig verwalteten Dienst und einen Partner, der Datenmodell, Wiederherstellung und Rechte betreut. Eine virtuelle Maschine mit selbst installiertem Datenbankserver verlagert deutlich mehr Wartungsverantwortung ins Unternehmen.
- Die Datenbank soll direkt von vielen Arbeitsplatz-PCs erreichbar sein: Überdenke die Architektur. Sicherer und wartbarer ist meist eine Anwendung oder Programmierschnittstelle zwischen Clients und Datenbank, statt den Datenbankport allgemein über das Internet freizugeben.
Office- und Windows-Integration richtig bewerten
Die beste Integration ist nicht zwangsläufig die Lösung mit dem Microsoft-Namen. Entscheidend ist, wie die Daten tatsächlich genutzt werden. Excel kann Daten aus unterschiedlichen Datenbanksystemen importieren oder über Power Query abrufen, sofern ein passender Connector, Treiber und freigegebener Zugriffsweg vorhanden ist. Das macht Excel zur Auswertungsoberfläche, nicht zur Datenbankverwaltung.
Bei Access-Anwendungen ist besondere Vorsicht nötig. Eine Access-Oberfläche kann über ODBC mit einer Serverdatenbank verbunden werden, doch Formulare, Abfragen und VBA-Code können vom bisherigen Datenbankverhalten abhängen. Der Wechsel zu einer Cloud-Datenbank ist daher ein Migrationsprojekt und kein bloßes Verschieben einer Datei. Latenz fällt stärker auf, wenn ein Formular viele einzelne Abfragen nacheinander ausführt.
Für Windows-Anmeldungen muss außerdem zwischen lokalem Windows-Konto, Microsoft-Konto und Microsoft Entra ID unterschieden werden. Eine Anmeldung am Windows-PC gewährt nicht automatisch Zugriff auf eine Cloud-Datenbank. Der Datenbankdienst oder die vorgeschaltete Anwendung benötigt ein eigenes, sauber eingerichtetes Identitäts- und Berechtigungsmodell.
Sicherheit beginnt nicht beim Backup
Automatische Sicherungen sind wichtig, reichen aber nicht aus. Eine Cloud-Datenbank kann technisch gesichert sein und trotzdem durch zu weit gefasste Benutzerrechte, kompromittierte Konten oder fehlerhafte Anwendungen Daten verlieren. Kleine Unternehmen benötigen mindestens getrennte Administrator- und Anwendungskonten, Mehrfaktor-Authentifizierung für Verwaltungszugänge und ein Verfahren für ausgeschiedene Beschäftigte.
Der Datenbankzugriff sollte auf notwendige Systeme begrenzt werden. Wo möglich, kommuniziert die Anwendung über private oder eingeschränkte Netzwerkwege mit der Datenbank. Ist ein öffentlicher Endpunkt erforderlich, müssen Firewall-Regeln, verschlüsselte Verbindungen und Authentifizierung zusammenpassen. Eine IP-Freigabe allein ersetzt kein Berechtigungskonzept.
Ebenso wichtig ist ein überprüfter Wiederherstellungsplan. Im jeweiligen Cloud-Portal muss ermittelt werden, wie lange Sicherungen aufbewahrt werden, auf welchen Zeitpunkt sich Daten zurücksetzen lassen und ob die Wiederherstellung eine neue Datenbank erzeugt. Mindestens ein Test mit unkritischen Daten zeigt, ob Anwendung, Benutzerrechte und Verbindungszeichenfolgen nach einer Wiederherstellung wieder funktionieren.
Kosten mit einem Nutzungsszenario kalkulieren
Der monatliche Datenbankpreis besteht selten nur aus einem einzelnen Tarifwert. Für einen belastbaren Vergleich sollten Unternehmen bei jedem Anbieter dieselben Positionen erfassen:
- laufende Rechenleistung oder verbrauchsabhängige Nutzung,
- bereitgestellter Daten- und Sicherungsspeicher,
- Ausfallsicherheits- oder Replikationsoptionen,
- ausgehende Datenübertragung und Verbindungen zwischen Regionen oder Clouds,
- Lizenzkosten der Datenbank-Engine, falls sie nicht enthalten sind,
- Überwachung, Support und Arbeitszeit des betreuenden Dienstleisters,
- Test-, Entwicklungs- und Wiederherstellungsumgebungen.
Ein neutrales Rechenschema für einen Monat lautet:
Monatskosten = Datenbankdienst + Speicher + Sicherungen + Datenübertragung + Zusatzdienste + Betreuung
Beispielhafte Planwerte ohne Bezug zu einem Marktpreis: Der Datenbankdienst wird im Angebot mit 120 Euro pro Monat angesetzt, Speicher und Sicherungen mit zusammen 35 Euro, Zusatzdienste mit 20 Euro und zwei Betreuungsstunden mit insgesamt 160 Euro. Bei vernachlässigbarer berechneter Datenübertragung ergibt sich:
120 Euro + 35 Euro + 0 Euro + 20 Euro + 160 Euro = 335 Euro pro Monat
Der Zahlencheck zeigt, dass in diesem Szenario nicht der Cloud-Dienst, sondern die Summe aus Betrieb und Betreuung den Ausschlag gibt. Für den echten Vergleich müssen die Beispielwerte durch Beträge aus dem Anbieterrechner, dem Lizenzportal und dem Dienstleisterangebot ersetzt werden. Alle Kandidaten benötigen dabei dieselbe Datenmenge, Sicherungsdauer und Verfügbarkeitsanforderung.
Ein begrenzter Test verhindert teure Fehlentscheidungen
Vor der endgültigen Migration sollte ein kleiner Prototyp mit repräsentativen, möglichst anonymisierten Testdaten entstehen. Er muss nicht die gesamte Anwendung abbilden. Aussagekräftig sind Anmeldung, typischer Lesevorgang, typischer Schreibvorgang, ein Bericht sowie die Wiederherstellung einer Testdatenbank.
Notiere für jeden Kandidaten dieselben Ergebnisse: benötigte Einrichtungszeit, Antwortverhalten aus dem Unternehmensnetz, Aufwand für Benutzerrechte, Importdauer, Fehlermeldungen der Anwendung und geschätzte Monatskosten unter derselben Lastannahme. Scheitert bereits der verwendete Treiber oder eine unverzichtbare Datenbankfunktion, sollte die Migration nicht mit zusätzlichen Tarifoptionen schöngerechnet werden.
Für viele Microsoft-orientierte kleine Unternehmen ergibt sich daraus eine klare Startreihenfolge: Azure SQL Database für bestehende SQL-Server-nahe Anwendungen, Azure Database for PostgreSQL für neue PostgreSQL-Projekte und Dataverse für Lösungen innerhalb der Power Platform. Amazon RDS und Google Cloud SQL sind gleichwertig zu prüfende Alternativen, wenn Anwendung und Fachwissen bereits in der jeweiligen Cloud liegen. Die endgültige Entscheidung sollte der Anwendung folgen, nicht dem Betriebssystem auf den Büro-PCs.
