Entscheidung & Vergleich

Welcher Datenbankdienst passt zu deiner Anwendung in AWS und Azure?

Für die allermeisten Anwendungen ist eine verwaltete relationale Datenbank die richtige Wahl, auch wenn NoSQL moderner klingt. DynamoDB und Cosmos DB spielen ihre Stärke erst aus, wenn das Zugriffsmuster vorher feststeht. Ein Data Warehouse kommt dazu, nicht anstelle, und es ersetzt keine Transaktionsdatenbank.

4 Kapitel mit allen Befehlen
Zwei IT-Entscheider vergleichen Plattformoptionen an einem großen Bildschirm
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Auswahl so oft schiefgeht

Die Entscheidung fällt fast immer zu früh. In der ersten Woche eines Projekts steht das Datenmodell noch nicht, die Abfragen sind unbekannt, und trotzdem wird bereits ein Dienst festgelegt, meist der, den jemand im Team zuletzt genutzt hat. Bei relationalen Datenbanken verzeiht das der Betrieb, weil sich neue Abfragen über Indizes nachrüsten lassen. Bei DynamoDB und Cosmos DB nicht: Dort legt der Partitionsschlüssel fest, welche Abfragen günstig sind, und dieser Schlüssel lässt sich nachträglich nicht ändern.

Der zweite blinde Fleck sind die Preismodelle. Sie unterscheiden sich nicht in Nuancen, sondern grundlegend. Verbrauchsabhängige Abrechnung rechnet je Anfrage, bereitgestellte Kapazität rechnet je Stunde, unabhängig davon, ob jemand zugreift. Cosmos DB berechnet Anfrageeinheiten pro Sekunde mit einem Mindestwert je Container, und Azure SQL kann in der Variante ohne feste Kapazität pausieren. Bei gleicher Funktion liegt zwischen der günstigsten und der teuersten Variante regelmäßig ein Faktor fünf.

Zum Schluss kommen die Anforderungen, die eigentlich am Anfang stehen müssten: Verfügbarkeit, Wiederanlaufzeit, Aufbewahrung der Sicherungen, Region, Verschlüsselung mit eigenen Schlüsseln. Einige davon lassen sich nur beim Anlegen entscheiden. Zonenredundanz nachträglich einzuschalten, die Region zu wechseln oder auf kundeneigene Schlüssel umzustellen bedeutet bei mehreren Diensten schlicht eine Migration, und die kostet dann ein Vielfaches der ursprünglichen Einrichtung.

Miniatur-Szene: zwei Plattformen nebeneinander mit unterschiedlichen Cloud-Bausteinen, dazwischen eine Waage

Der Auswahlpfad in sechs Schritten

  1. 01 Zugriffsmuster und geplante Abfragen aufschreiben
  2. 02 Relational als Ausgangspunkt, NoSQL bewusst begründen
  3. 03 Verwalteter Dienst statt Datenbank auf eigener Maschine
  4. 04 Preismodell an das gemessene Lastprofil anpassen
  5. 05 Verfügbarkeit, Sicherung und Region festlegen
  6. 06 Auswertungen erst danach ins Data Warehouse trennen
Was du mitnimmst

Fünf Fragen, die die Auswahl entscheiden

Beantworte diese fünf Fragen schriftlich, bevor ein Dienst angelegt wird. Danach bleibt in den meisten Fällen genau eine sinnvolle Option übrig.

Steht das Zugriffsmuster schon fest?

Wenn du heute nicht aufschreiben kannst, welche Abfragen die Anwendung stellt, nimm eine relationale Datenbank. Sie erlaubt neue Abfragen ohne Umbau des Datenmodells. NoSQL ist die richtige Wahl, wenn die Zugriffe bekannt, wiederkehrend und über einen klaren Schlüssel adressierbar sind, also etwa Sitzungsdaten, Katalogeinträge oder Ereignisströme.

Transaktionen oder Auswertungen?

Beides in einer Datenbank zu machen, fällt genau dann auf die Füße, wenn der Monatsbericht die Bestellannahme ausbremst. Trenne früh: Transaktionen bleiben in der relationalen Datenbank, Auswertungen wandern nach Amazon Redshift, Azure Synapse oder Microsoft Fabric. Die Trennung nachträglich einzuziehen ist deutlich aufwendiger als von Beginn an.

Wie viel Betrieb willst du selbst übernehmen?

Ein verwalteter Dienst nimmt dir Einspielen von Updates, Sicherung, Ausfallsicherheit und Überwachung ab. Eine Datenbank auf einer eigenen Maschine lohnt nur bei harten Vorgaben des Herstellers, bei Erweiterungen mit Dateisystemzugriff oder bei Lizenzen, die an Kerne gebunden sind. Alles andere spricht für den verwalteten Dienst.

Wie schwankt die Last, und was kostet Leerlauf?

Gleichmäßige Last läuft mit bereitgestellter Kapazität günstiger, stark schwankende oder unbekannte Last mit verbrauchsabhängiger Abrechnung. Für Entwicklung und Test ist die Fähigkeit zu pausieren der größte Hebel: Azure SQL ohne feste Kapazität und DynamoDB im verbrauchsabhängigen Modus kosten im Leerlauf fast nichts.

Welche Auflagen gelten für die Daten?

Personenbezogene Daten, Regionen in der EU, Verschlüsselung mit eigenen Schlüsseln, Aufbewahrungsfristen und Nachweise für Prüfungen nach DSGVO, NIS2 oder BSI C5 gehören vor die Auswahl, nicht danach. Die Region eines Dienstes lässt sich nicht umschalten, und genau daran scheitern nachträgliche Anpassungen am häufigsten.

Tutorial

Von der Abfrageliste bis zur abgesicherten Instanz

Für die allermeisten Anwendungen ist eine verwaltete relationale Datenbank die richtige Wahl, NoSQL lohnt sich erst, wenn das Zugriffsmuster vorher feststeht. Deshalb steht am Anfang keine Technik, sondern die Liste der Abfragen, die deine Anwendung stellt. Danach legst du die relationale Variante auf beiden Plattformen an, rechnest den NoSQL-Weg mit seinem Preismodell durch und prüfst zum Schluss Verfügbarkeit, Sicherung und Wiederherstellung.

01

Schritt 1: Zugriffsmuster vor der Technik festhalten

Schreibe zuerst auf, welche Abfragen die Anwendung stellt, wie oft und mit welchem Schlüssel. Erst danach ist die Auswahl eine technische Frage.

Zugriffsmuster aus dem Bestand ablesen
-- PostgreSQL: die teuersten Abfragen sichtbar machen
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT calls,
       round(mean_exec_time::numeric, 2) AS ms_mittel,
       rows,
       left(query, 80) AS abfrage
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

-- Verhältnis von Lesen zu Schreiben je Tabelle
SELECT relname, seq_scan, idx_scan, n_tup_ins, n_tup_upd, n_tup_del
FROM pg_stat_user_tables
ORDER BY seq_scan + idx_scan DESC
LIMIT 20;

Wer bereits eine Datenbank betreibt, muss das Zugriffsmuster nicht schaetzen. Diese beiden Abfragen liefern die Grundlage der Entscheidung: welche Abfragen die Last erzeugen, wie viele Zeilen sie liefern und ob eine Tabelle ueberwiegend gelesen oder geschrieben wird. Bei einer Neuentwicklung ersetzt eine schriftliche Liste der geplanten Abfragen diesen Schritt.

Zugriffsmuster und passender Dienst

MusterPasstPasst nicht
Viele verschiedene Abfragen, Verknüpfungen, BerichteAmazon RDS oder Aurora, Azure SQL-Datenbank, Azure Database for PostgreSQLDynamoDB, weil jede neue Abfrage einen weiteren Index braucht
Bekannter Schlüssel, sehr hohe Zugriffszahl, feste MusterAmazon DynamoDB, Azure Cosmos DBEine einzelne große relationale Instanz, die vertikal wachsen muss
Dokumente mit wechselndem Aufbau, weltweite VerteilungAzure Cosmos DB, Amazon DocumentDBData Warehouse, das auf Massenauswertung ausgelegt ist
Auswertungen über Millionen Zeilen mit AggregationAmazon Redshift, Azure Synapse oder Microsoft FabricTransaktionsdatenbank, die dabei den Tagesbetrieb ausbremst
Zeitreihen aus Sensoren, Metriken und ProtokollenAmazon Timestream, Azure Data ExplorerKlassische Tabelle mit Zeitstempelindex und wachsendem Index
02

Schritt 2: Den relationalen Standardweg anlegen

Der verwaltete relationale Dienst ist der Ausgangspunkt, von dem aus jede andere Wahl begründet werden muss. Diese beiden Befehle zeigen die wichtigsten Schalter.

PostgreSQL auf AWS und Azure SQL-Datenbank
# AWS: verwaltete PostgreSQL-Instanz, zwei Zonen, 14 Tage Sicherung
aws rds create-db-instance \
  --db-instance-identifier prod-pg \
  --engine postgres \
  --db-instance-class db.m6g.large \
  --allocated-storage 100 \
  --master-username dbadmin \
  --manage-master-user-password \
  --multi-az \
  --backup-retention-period 14 \
  --storage-encrypted \
  --no-publicly-accessible

# Azure: SQL-Datenbank ohne feste Kapazität, pausiert nach 60 Minuten
az sql db create \
  --resource-group rg-data --server sql-prod --name appdb \
  --edition GeneralPurpose --compute-model Serverless \
  --family Gen5 --capacity 4 --auto-pause-delay 60 \
  --backup-storage-redundancy Zone

--manage-master-user-password legt das Kennwort direkt im Secrets Manager ab, statt es im Skript stehen zu lassen. Auf der Azure-Seite ist --auto-pause-delay der größte Hebel für Testumgebungen: Die Datenbank pausiert nach der angegebenen Zeit und kostet dann nur noch Speicher, dafür dauert der erste Zugriff danach einige Sekunden.

Wann eine Datenbank auf einer eigenen Maschine trotzdem richtig ist

  • Der Hersteller der Anwendung unterstützt nur eine bestimmte Nebenversion oder eigene Erweiterungen
  • Es wird Zugriff auf das Dateisystem gebraucht, etwa für Ladeprozesse oder Spezialerweiterungen
  • Eine Lizenz ist an Kerne gebunden und im verwalteten Dienst insgesamt teurer
  • Dieselben Abläufe sollen im eigenen Rechenzentrum und in der Cloud identisch funktionieren

Ob eine bestehende Datenbank unverändert umzieht oder gleich neu aufgesetzt wird, ist eine eigene Entscheidung mit deutlich unterschiedlichen Kosten. Die Abwägung dazu steht unter Lift and Shift oder Neubau.

03

Schritt 3: Den NoSQL-Weg durchrechnen

NoSQL ist keine Vereinfachung, sondern eine Verschiebung des Aufwands vom Betrieb in den Entwurf. Das Preismodell entscheidet mit.

Tabelle und Container mit passendem Abrechnungsmodell
# AWS: DynamoDB verbrauchsabhängig, ohne bereitgestellte Kapazität
aws dynamodb create-table \
  --table-name orders \
  --attribute-definitions AttributeName=pk,AttributeType=S \
                          AttributeName=sk,AttributeType=S \
  --key-schema AttributeName=pk,KeyType=HASH \
               AttributeName=sk,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST

# Azure: Cosmos DB mit automatisch skalierendem Durchsatz
az cosmosdb create --name cosmos-prod --resource-group rg-data \
  --locations regionName=germanywestcentral failoverPriority=0 \
  --enable-automatic-failover true

az cosmosdb sql database create --account-name cosmos-prod \
  --resource-group rg-data --name shop

az cosmosdb sql container create --account-name cosmos-prod \
  --resource-group rg-data --database-name shop --name orders \
  --partition-key-path /kundenId --max-throughput 4000

--max-throughput schaltet die automatische Skalierung ein. Der Dienst rechnet dann zwischen zehn Prozent und dem angegebenen Höchstwert ab, fällt aber nie auf null. Bei DynamoDB entfällt dieser Sockel im Modus PAY_PER_REQUEST vollständig, dafür ist der Preis je einzelner Anfrage höher als bei gut ausgelasteter bereitgestellter Kapazität.

Preismodelle und wann sie passen

ModellRechnet abPasst bei
DynamoDB verbrauchsabhängigJe Lese- und SchreibvorgangUnbekannte oder stark schwankende Last, Test- und Entwicklungsumgebungen
DynamoDB bereitgestelltReservierte Kapazitätseinheiten je StundeGleichmäßige, gut vorhersagbare Last mit hoher Auslastung
Cosmos DB bereitgestelltAnfrageeinheiten pro Sekunde, dauerhaftKonstante Last, aber mit Mindestwert je Container auch im Leerlauf
Cosmos DB automatisch skalierendZwischen zehn Prozent und dem HöchstwertTages- und Wochenrhythmus mit klaren Spitzen
Azure SQL ohne feste KapazitätNur genutzte Rechenzeit plus SpeicherEntwicklung, Test und Anwendungen mit echten Pausen
04

Schritt 4: Verfügbarkeit, Sicherung und Region festlegen

Eine eingerichtete Sicherung ohne getesteten Rücklauf ist eine Annahme. Diese Prüfung gehört einmal vollständig durchgespielt, bevor Daten produktiv werden.

Wiederherstellung testen, nicht nur einrichten
# AWS: Wiederherstellung auf einen Zeitpunkt, in eine neue Instanz
aws rds describe-db-instances --db-instance-identifier prod-pg \
  --query 'DBInstances[0].LatestRestorableTime'

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-pg \
  --target-db-instance-identifier prod-pg-restore-test \
  --restore-time 2026-07-20T09:00:00Z

# Azure: Wiederherstellungspunkt zurückspielen
az sql db restore --resource-group rg-data --server sql-prod \
  --name appdb --dest-name appdb-restore-test \
  --time 2026-07-20T09:00:00Z

# Aufräumen nicht vergessen
aws rds delete-db-instance --db-instance-identifier prod-pg-restore-test \
  --skip-final-snapshot
az sql db delete --resource-group rg-data --server sql-prod \
  --name appdb-restore-test --yes

Beide Wege erzeugen eine zweite Instanz, die ab der ersten Minute Geld kostet. Trage den Test in den Kalender ein und setze die Erinnerung zum Löschen gleich mit. Vergessene Wiederherstellungstests sind ein regelmäßiger Posten auf der Cloud-Rechnung, und sie fallen erst bei der nächsten Abrechnung auf.

Vor der Freigabe abhaken

  • Region und Ausweichregion liegen in der EUPersonenbezogene Daten außerhalb der EU zu verarbeiten erzeugt Begründungspflichten nach DSGVO und ist in Ausschreibungen der öffentlichen Hand häufig ausgeschlossen. Die Region eines Dienstes lässt sich nicht umschalten, es bleibt nur eine vollständige Migration.
  • Die Verschlüsselung mit eigenen Schlüsseln ist geklärtDer anbieterverwaltete Schlüssel genügt vielen Prüfungen, aber nicht allen. Ein Wechsel auf kundeneigene Schlüssel im Nachhinein bedeutet bei mehreren Diensten das Neuanlegen der Datenbank samt Datenumzug.
  • Ein vollständiger Rücklauf ist einmal getestet wordenErst der Test zeigt, wie lange die Wiederherstellung wirklich dauert und ob dieser Wert zur zugesagten Wiederanlaufzeit passt. Ohne diese Zahl ist jede Zusage im Notfallplan geraten.
  • Zonenredundanz oder Multi-AZ ist bewusst entschiedenBei einigen Diensten lässt sich das nur beim Anlegen festlegen. Wer es später braucht, migriert die Datenbank ein zweites Mal, mit Ausfallzeit und erneutem Test.
  • Der Zugriff läuft ohne öffentlichen EndpunktEine Datenbank mit öffentlicher Adresse wird binnen Stunden nach dem Anlegen automatisiert gescannt. Private Endpunkte und Sicherheitsgruppen gehören von Beginn an dazu, nicht in eine spätere Härtungsrunde.
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Gut zu wissen

Häufige Fragen zu Datenbanken in der Cloud

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wann ist DynamoDB die richtige Wahl und wann nicht?
DynamoDB passt, wenn die Zugriffe bekannt und über einen klaren Schlüssel adressierbar sind, die Zugriffszahl hoch ist und gleichbleibend niedrige Antwortzeiten zählen. Typisch sind Sitzungsdaten, Katalogeinträge, Ereignisströme und Warenkörbe. Ungeeignet ist DynamoDB, wenn viele unterschiedliche Abfragen mit Verknüpfungen und Aggregationen anfallen oder wenn das Datenmodell noch in Bewegung ist. Jede nicht vorgesehene Abfrage braucht dann einen zusätzlichen Index, und der kostet dauerhaft Speicher und Schreibvorgänge.
Was unterscheidet Azure SQL-Datenbank und SQL Managed Instance?
Die Azure SQL-Datenbank ist ein einzelner Datenbankdienst mit dem geringsten Betriebsaufwand, dafür fehlen instanzweite Funktionen wie SQL Server Agent, Verbindungsserver oder datenbankübergreifende Abfragen. SQL Managed Instance bildet eine vollständige SQL-Server-Instanz nach und ist deshalb das Ziel für Migrationen aus dem eigenen Rechenzentrum, bei denen der Anwendungscode unverändert bleiben soll. Faustregel: Neuentwicklung nimmt die Datenbank, Bestandsmigration nimmt die Managed Instance.
Brauchen wir wirklich ein eigenes Data Warehouse?
Nicht am Anfang. Solange Berichte in Sekunden laufen und die Transaktionsdatenbank dabei nicht spürbar langsamer wird, reicht eine Lesereplik völlig aus. Ein Data Warehouse lohnt sich, sobald Auswertungen über viele Millionen Zeilen laufen, mehrere Quellen zusammengeführt werden oder Fachbereiche selbst Abfragen stellen sollen. Der Auslöser ist fast immer der Moment, in dem der Monatsbericht den Tagesbetrieb ausbremst, und genau dann ist die Trennung fällig.
Lohnt sich eine Datenbank auf einer eigenen Maschine noch?
In wenigen, klar benennbaren Fällen. Dazu gehören harte Vorgaben des Anwendungsherstellers zu Version und Erweiterungen, Erweiterungen mit Zugriff auf das Dateisystem, an Kerne gebundene Lizenzen und der Wunsch, im eigenen Rechenzentrum und in der Cloud identische Abläufe zu fahren. In allen anderen Fällen überwiegt der verwaltete Dienst deutlich, weil Einspielen von Updates, Sicherung, Ausfallsicherheit und Überwachung ohne eigenen Aufwand mitkommen.
Welche Region sollten wir für personenbezogene Daten wählen?
Eine Region innerhalb der EU, und die Ausweichregion ebenfalls. Auf AWS sind das etwa Frankfurt und Irland, auf Azure Deutschland Mitte-West und Westeuropa. Damit ist die Frage nach dem Speicherort beantwortet, nicht aber die nach dem Zugriff: Support- und Betriebszugriffe aus Drittstaaten gehören in den Vertrag zur Auftragsverarbeitung und in die Risikobetrachtung. Wer strengere Vorgaben hat, prüft zusätzlich Angebote mit vertraglich zugesicherter Datenhaltung und Betrieb ausschließlich in der EU.

Zuletzt geprüft am 28. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Der Kurs hat sein Ziel erreicht. Der Trainer konnte die Inhalte gut rüberbringen und der Praxisanteil und die Übungsumgebung war sehr gut.
Rückmeldung aus dem Kurs „Terraform mit Azure – Der kompakte Praxiskurs für Ihren Cloud-Erfolg“
Super, komplett auf uns und unsere Bedürfnisse eingegangen. Der Tag hat uns viel geholfen und wir könnten das alles in unserem Arbeitsalltag nutzen.
Rückmeldung aus dem Kurs „DP-080 Training: Abfragen von Daten mit Microsoft Transact-SQL (DP-080T00)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Die Auswahl mit dem Team belastbar machen

Wenn die Entscheidung ansteht, hilft ein gemeinsamer Wissensstand mehr als jede Vergleichstabelle. Planning and Designing Databases on AWS geht die Auswahl auf AWS-Seite systematisch durch, Amazon AWS DynamoDB - Kompaktschulung und Azure Cosmos DB - Kompaktschulung nehmen sich die beiden NoSQL-Dienste vor, und DP-300 deckt den Betrieb der Azure-SQL-Dienste ab. Alle Kurse gibt es als Präsenztermin und Live-Online, auf Wunsch auch als geschlossenes Team-Training entlang eures eigenen Datenmodells.