Wenige technische Fragen werden häufiger gestellt — und schlechter beantwortet — als „Soll ich SQL oder NoSQL nehmen?“ Es klingt nach einem sauberen Entweder-oder, und fast jede Antwort behandelt es so. Beide Instinkte sind falsch.
Die ehrliche Version: „SQL vs. NoSQL“ ist ein Scheingegensatz. SQL ist eine Abfragesprache. NoSQL bedeutet „not only SQL“ — ein Dach über einem halben Dutzend sehr unterschiedlicher Datenbankmodelle. Sie direkt zu vergleichen ist, als frage man „Limousine oder Nicht-Limousine?“ Die eigentliche Frage dreht sich um Datenmodelle und Konsistenzgarantien. Sieht man die Landschaft so, wird die Datenbankwahl vom Münzwurf zur ingenieurmäßigen Entscheidung.
Dieser Leitfaden zeigt den Datenbank-Stammbaum, den Gegensatz ACID versus BASE, der die Systeme wirklich trennt, und einen Rahmen, um nach Zugriffsmustern statt nach Mode zu wählen.
Zuerst: Was „relational“ wirklich bedeutet
Lass das Branding weg. Eine relationale Datenbank speichert Daten in Tabellen — Zeilen und Spalten — wobei jede Tabelle ein definiertes Schema hat (welche Spalten existieren und welchen Typ jede hat). Tabellen sind über Schlüssel verbunden, und Fragen stellst du mit SQL, einer deklarativen Sprache: Du beschreibst was du willst, und die Datenbank findet heraus, wie.
Dieses Modell — 1970 erfunden und ein halbes Jahrhundert verfeinert — gibt dir drei Dinge, die man leicht unterschätzt, bis man sie verliert:
- Ein Schema, das deine Daten dokumentiert und fehlerhafte Schreibvorgänge ablehnt.
- Transaktionen — die Möglichkeit, mehrere Dinge als eine Alles-oder-nichts-Einheit zu ändern.
- Ad-hoc-Abfragen — du kannst nie geplante Fragen beantworten, mit Joins, Filtern und Aggregation, ohne deine Speicherung umzuschreiben.
PostgreSQL und MySQL sind die bekannten Beispiele. Wenn Leute „SQL-Datenbank“ sagen, meinen sie das.
NoSQL ist alles, was sich bewusst von Teilen dieses Modells entfernt — meist um Flexibilität, Skalierung oder eine Form zu gewinnen, die zu einem Zugriffsmuster hervorragend passt.
Der Datenbank-Stammbaum
„NoSQL“ verbirgt enorme Vielfalt. Hier die Familien, die zählen, jeweils mit dem, was sie sind, und wann sie gewinnen:
- Relational (PostgreSQL, MySQL) — Tabellen, Schema, SQL, starke Konsistenz. Der Standard für die meisten Anwendungen.
- Dokument (MongoDB) — speichert JSON-ähnliche Dokumente. Flexibles Schema, natürlich verschachtelte Daten. Stark, wenn Datensätze variieren und sich entwickeln.
- Key-Value (Redis) — ein riesiges Wörterbuch: ein Schlüssel verweist auf einen Wert. Blitzschnelle Lookups per Schlüssel, sonst nichts. Ideal für Caching, Sessions, Rate-Limits.
- Wide-Column (Cassandra, Bigtable) — riesige, nach Schlüssel partitionierte Tabellen für enormen Schreibdurchsatz und vorhersehbare Abfragen im großen Maßstab. Für Volumen gebaut, nicht für Joins.
- Graph (Neo4j) — Knoten und die Beziehungen zwischen ihnen. Gewinnt, wenn die Verbindungen das sind, was du abfragst: soziale Graphen, Betrugsringe, Empfehlungen.
- Time-Series (InfluxDB, TimescaleDB) — optimiert für zeitgestempelte Daten, die geordnet geschrieben und nach Bereich abgefragt werden. Metriken, Sensorwerte, Events.
- Search (Elasticsearch) — Volltextsuche und Relevanz-Ranking, keine exakten Lookups.
- Vektor (pgvector, Pinecone) — Ähnlichkeitssuche über Embeddings, das Rückgrat der KI-Retrieval.
Aus dieser Liste folgen sofort zwei Dinge. Erstens ist „NoSQL“ keine Wahl — es sind sieben. Zweitens sind mehrere davon gar keine Rivalen des Relationalen; sie sind Spezialisten, die man daneben stellt.
Die Achse, auf die es wirklich ankommt: ACID vs. BASE
Das Datenmodell ist das Was du speicherst. Die Konsistenzgarantie ist das Wie stark die Datenbank verspricht, dass deine Daten korrekt sind — und hier verläuft die eigentliche Trennlinie.
ACID — Korrektheit zuerst
Klassische relationale Datenbanken geben dir ACID:
- Atomicity (Atomarität) — eine Transaktion geschieht ganz oder gar nicht. Überweise Geld zwischen zwei Konten, und entweder ändern sich beide Seiten oder keine.
- Consistency (Konsistenz) — die Datenbank geht von einem gültigen Zustand in den nächsten über; Constraints werden nie verletzt.
- Isolation — gleichzeitige Transaktionen kommen sich nicht in die Quere; das Ergebnis ist, als liefen sie nacheinander.
- Durability (Dauerhaftigkeit) — einmal committet, überstehen Daten einen Absturz.
ACID ist der Grund, warum Banken, Bestellungen und Bestände in relationalen Datenbanken leben. Wenn „falsch“ teuer ist, sind diese Garantien ihren Preis wert.
BASE — Verfügbarkeit zuerst
Viele verteilte NoSQL-Systeme treffen den Gegentausch, zusammengefasst als BASE:
- Basically Available — das System antwortet weiter, auch bei Ausfällen.
- Soft state — Daten können im Fluss sein; Knoten müssen nicht jederzeit übereinstimmen.
- Eventually consistent — nach einem Schreibvorgang können Replikate kurz uneinig sein und konvergieren dann zum selben Wert.
BASE ermöglicht es einer Datenbank, hunderte Maschinen zu umspannen und verfügbar zu bleiben, wenn einige ausfallen. Der Preis: Ein Lesevorgang direkt nach einem Schreibvorgang kann leicht veraltete Daten liefern. Für einen Social-Feed oder einen Produktkatalog ist das in Ordnung. Für einen Kontostand nicht.
CAP: der Grund, warum du wählen musst
Darunter liegt das CAP-Theorem: Wenn eine Netzwerkpartition deine Knoten trennt, kann eine verteilte Datenbank Konsistenz (jeder Lesevorgang sieht den letzten Schreibvorgang) oder Verfügbarkeit (jede Anfrage bekommt eine Antwort) garantieren — aber nicht beides. Jedes verteilte System entscheidet sich für eine Seite, und diese Entscheidung zeigt sich direkt darin, wie deine Anwendung unter Last reagiert.
Das ist die wichtigste Idee bei der Datenbankwahl und verdient eine eigene Behandlung — ich gehe tief darauf ein in was das CAP-Theorem wirklich für die Datenbankwahl bedeutet. ACID und BASE sind zum großen Teil zwei Antworten auf die Frage, die CAP erzwingt.
Was tauscht „SQL vs. NoSQL“ also wirklich?
Jetzt bedeutet der Vergleich etwas. Stellt man den relationalen Standard den NoSQL-Alternativen gegenüber, treten die echten Trade-offs hervor:
| Dimension | Relational (SQL) | NoSQL (je nach Typ) |
|---|---|---|
| Schema | Fest, erzwungen, selbstdokumentierend | Flexibel oder schemalos |
| Konsistenz | Stark (ACID) | Oft eventuell (BASE), teils einstellbar |
| Abfragen | Reich, ad hoc, Joins über Tabellen | Schnell für das entworfene Muster; Joins begrenzt |
| Schreiben skalieren | Über Maschinen schwerer | Oft horizontal by design |
| Am besten bei | Beziehungen und Korrektheit zählen | Ein Zugriffsmuster muss extrem sein (Skalierung, Latenz, Form) |
Das Muster ist dasselbe wie bei jeder echten Architekturentscheidung: Du wählst nicht einfach versus komplex — du wählst, welchen Tausch du machst. Relational tauscht etwas Skalierungsflexibilität gegen Korrektheit und Abfragekraft. NoSQL tauscht einen Teil dieser Kraft gegen eine Form, die eine Aufgabe außergewöhnlich gut erledigt.
Wie man wirklich wählt
Ignoriere das Marketing. Die Datenbank folgt daraus, wie deine Anwendung Daten liest und schreibt. Arbeite diese Fragen ehrlich durch:
-
Wie sieht ein Zugriffsmuster aus? Schlägst du meist per einzelnem Schlüssel nach, ist ein Key-Value-Store ein Skalpell. Stellst du variierende Ad-hoc-Fragen, willst du SQLs Abfragekraft. Traversierst du Beziehungen („Freunde von Freunden, die X gekauft haben“), verdient eine Graph-Datenbank ihren Platz.
-
Wie stark muss die Konsistenz sein? Geld, Bestände, Buchungen → ACID, relational. Ein „Likes“-Zähler oder ein Aktivitäts-Feed → eventuelle Konsistenz reicht, und BASE kauft dir Skalierung.
-
Welche Form haben deine Daten? Einheitliche, verwandte Datensätze → Tabellen. Tief verschachtelte, variierende Dokumente → ein Dokument-Store. Ein Strom zeitgestempelter Punkte → Time-Series.
-
Wie groß ist deine echte Skalierung? Sei ehrlich. Die meisten Anwendungen wachsen nie über eine gut betriebene relationale Datenbank mit Replikaten hinaus. „Skaliert nicht“ ist der häufigste — und am häufigsten falsche — Grund, zu NoSQL zu greifen. Löse das Problem, das du hast, nicht das, das du dir vorstellst.
-
Muss eine Last extrem sein? Extremer Schreibdurchsatz, Mikrosekunden-Lookups, Ähnlichkeitssuche über Millionen Vektoren — ein echtes, konkretes Extrem ist der ehrliche Grund, einen Spezial-Store zu ergänzen.
Beachte die Reihenfolge: Muster und Korrektheit zuerst, Skalierung später. Allein diese Reihenfolge verhindert die meisten Datenbankfehler.
Die ehrliche Realität: Es ist selten eine Datenbank
Was erfahrene Teams tatsächlich tun: Sie nutzen mehr als eine. Das ist Polyglot Persistence — die vernünftige Einsicht, dass verschiedene Daten verschiedene Formen haben. Ein einzelnes Produkt kann PostgreSQL als Source of Truth betreiben, Redis für Caching und Sessions, Elasticsearch für Suche und einen Vektor-Store für KI-Funktionen. Jedes tut das eine, worin es am besten ist.
Aber Polyglot Persistence ist ein Ziel, kein Startpunkt. Jede zusätzliche Datenbank ist ein weiteres System zum Betreiben, Überwachen, Sichern und Durchdenken. Der disziplinierte Weg:
- Starte mit einer relationalen Datenbank. PostgreSQL allein bewältigt relationale Daten, JSON-Dokumente, Key-Value-Muster, Volltextsuche und Vektoren — oft jahrelang, ein System.
- Ergänze einen Spezial-Store erst, wenn ein konkreter, gemessener Druck es verlangt — nicht weil ein Blogpost sagte, relational skaliere nicht.
- Extrahiere, rate nicht. Wenn ein echter Engpass oder ein Zugriffsmuster auftaucht, verschiebe diese eine Last in die dafür gebaute Datenbank.
Und denk daran: Selbst innerhalb einer relationalen Datenbank gibt es viel Spielraum, bevor du sie verlassen musst — die meisten „die Datenbank ist langsam“-Probleme sind in Wahrheit fehlende Indizes und unoptimierte Abfragen, kein Signal zum Paradigmenwechsel. Wenn du eine einzelne relationale Maschine bei einer schreiblastigen Last wirklich überwächst, beginnt genau dort ein Wide-Column-Store wie Bigtable sich zu lohnen.
Das Fazit
„SQL vs. NoSQL“ war nie die eigentliche Frage. Die echten Fragen lauten: Welche Form haben meine Daten, wie stark muss meine Konsistenz sein, und wie sieht mein Zugriffsmuster aus? Beantworte sie, und die Datenbank wählt sich selbst.
SQL — das relationale Modell — bleibt der richtige Standard für die meisten Anwendungen, weil ein Schema, echte Transaktionen und Ad-hoc-Abfragen früh mehr wert sind als jede einzelne Optimierung. NoSQL ist eine Menge von Spezialisten, jeder brillant in einer Aufgabe und unauffällig im Rest. ACID und BASE sind die zwei ehrlichen Antworten auf die Konsistenzfrage, die CAP jedem verteilten System aufzwingt.
Wähle nach deinen Mustern, starte relational und ergänze einen Spezialisten erst, wenn ein echtes Problem — kein modisches — es vor dich stellt.
