Wann SQL, wann NoSQL?

Acht Lektionen Theorie liegen hinter dir – jetzt die wichtigste Frage der gesamten Datenbank-Welt: Wann nehme ich was? Diese Lektion ist eine pragmatische Entscheidungshilfe. Sie kombiniert das Wissen aus den vorigen Lektionen zu einem Werkzeugkasten für reale Architektur-Entscheidungen.

Vorab das wichtigste Pragma: es gibt keine pauschal richtige Antwort. „SQL ist besser" oder „NoSQL ist moderner" sind beide falsch. Die Frage ist immer: welches Werkzeug passt zu welchem Problem? Wer das Werkzeug vor dem Problem wählt, hat den ersten Fehler schon gemacht.

1) Die fünf Schlüsselfragen

Wenn du vor der Wahl stehst, gibt es fünf Fragen, deren Antworten dich meistens schon zur Lösung führen. In der Reihenfolge ihrer Wichtigkeit:

Wie sind die Daten strukturiert? Streng tabellarisch mit festen Spalten, oder variabel mit unterschiedlichen Feldern pro Datensatz?
Wie wichtig sind Transaktionen? Brauchst du harte ACID-Garantien (z.B. Geldbeträge) oder reicht eventually consistent?
Wie groß ist die Datenmenge / wie hoch ist die Last? Passt es auf einen großen Server, oder muss horizontal über viele Knoten skaliert werden?
Welche Abfragen sind typisch? Komplexe JOINs und Aggregationen, oder einfache Lookups nach Schlüssel?
Welche Tools und welches Know-how hat das Team? Auch der „menschliche Faktor" zählt.

Diese fünf Fragen lassen sich zu einem Entscheidungsbaum verdichten. Klick dich durch:

2) Der Entscheidungsbaum

Interaktive Entscheidungshilfe

Dieser Baum ist eine Vereinfachung – in der Realität fließen mehr Faktoren ein. Aber als Sortier-Heuristik funktioniert er erstaunlich gut. Wenn du am Ende „SQL" landest, ist das meistens richtig. Wenn du bei einem NoSQL-System landest, schau nochmal genau hin – die Entscheidung gegen SQL braucht eine starke Begründung, kein vager „klingt modern".

3) Vergleichs-Matrix nach Kriterien

Wenn du eine bestimmte Anforderung hast, zeigt dir diese Tabelle, was jeweils besser ist. Eine Eigenschaft bedeutet nicht automatisch „immer gewinnen" – sie zeigt die Tendenz:

SQL vs. NoSQL nach Kriterium

Kriterium

SQL stärker

NoSQL stärker

Strukturierte Daten

✓ feste Schemas, klare Spalten

– flexibles Schema möglich, aber unnötig

Variable Daten

– NULL-Hölle, viele ALTER TABLE

✓ pro Dokument andere Felder ok

ACID-Transaktionen

✓ Kernkompetenz, voll ausgereift

– vorhanden, aber meist teurer

Horizontale Skalierung

– schwierig, teuer (Sharding)

✓ von Anfang an dafür gebaut

Komplexe JOINs & Reports

✓ JOINs sind Standard

– teuer oder unmöglich

Hohe Schreiblast

– Locks & Logs werden Bottleneck

✓ horizontal verteilbar

Cache / Sub-ms Latenz

– Disk-I/O als Limit

✓ Redis ist hier konkurrenzlos

Graph-/Beziehungs-Daten

– tiefe JOINs werden teuer

✓ Graph-DB wie Neo4j

Standards & Tooling

✓ SQL ist normiert, viele Tools

– jede DB hat eigene Sprache

Personal-Verfügbarkeit

✓ fast jede*r Entwickler*in kennt SQL

– NoSQL-Spezialisten seltener

Wenn du in deiner Anforderungs-Liste mehrere ✓ in einer Spalte siehst, ist das ein starker Hinweis. Wenn die ✓ gemischt sind, hilft die Polyglot-Persistence-Strategie aus dem nächsten Abschnitt.

4) Polyglot Persistence – beide nutzen

Die wichtigste Erkenntnis dieser Lektion: in nicht-trivialen Architekturen ist „SQL vs. NoSQL" oft die falsche Frage. Die richtige Frage ist „welche Daten in welche DB?". Das nennt man Polyglot Persistence – mehrere Datenspeicher parallel, jeden für das was er kann. Eine typische Architektur eines mittelgroßen Online-Shops sieht z.B. so aus:

Polyglot Persistence – Beispiel-Architektur

PostgreSQL (SQL)

Bestellungen, Rechnungen, Kunden, Buchhaltung. Alles mit hartem ACID-Anspruch.

MongoDB (Dokument)

Produktkatalog mit variablen Attributen pro Produkt-Typ (Buch hat Autor, Schuh hat Größe).

Redis (Key-Value)

Cache für gerenderte Seiten, Session-Store, Warenkörbe, Rate-Limiting, Counter.

Elasticsearch (Search)

Volltextsuche im Produktkatalog mit Tippfehler-Toleranz, Filter-Facetten.

Neo4j (Graph)

„Kunden die X kauften, kauften auch Y." Empfehlungs-Algorithmen.

Klingt aufwändig? Ist es auch – Polyglot Persistence bringt Betriebs-Komplexität: mehrere Systeme zu monitoren, zu sichern, zu skalieren. In kleinen Projekten Overkill. Erst lohnenswert, wenn das Wachstum von Daten und Anforderungen mit einer einzelnen DB schmerzhaft wird. Faustregel: starte einfach mit einer relationalen DB, ergänze gezielt um spezialisierte Stores wenn ein konkretes Problem entsteht.

5) Typische Fehlentscheidungen

Bevor wir zu konkreten Szenarien kommen, ein paar verbreitete Fallen, die immer wieder Geld und Nerven kosten:

NoSQL wählen, weil es „skaliert". Skalierung ist erst relevant, wenn man eine wahrnehmbare Last hat. Bis dahin ist eine relationale DB einfacher zu betreiben. Wer eine kleine Anwendung „cloud-native auf NoSQL" baut, schafft Komplexität ohne Nutzen.
NoSQL wählen, weil das Schema „flexibel" sein soll. Oft heißt das nur, dass das Datenmodell unklar ist. Lieber das Modell sauber durchdenken und auf SQL setzen – sonst landet die Komplexität nur in der Anwendung statt im Schema.
SQL wählen, ohne über Skalierung nachzudenken. Manche Use Cases (z.B. IoT mit Milliarden Datenpunkten pro Tag) sind mit einer einzelnen SQL-DB nicht handhabbar. Hier ist NoSQL keine Option, sondern Pflicht.
„Wir nehmen NoSQL und denken später über JOINs nach": wenn die Anwendung später Reports braucht, ist das Daten-Design oft so, dass $lookup-Ketten oder Datenduplizierung nötig sind. Vorher überlegen!
Cache und primäre DB verwechseln: Redis hält Daten im RAM. Wenn die nicht zusätzlich woanders persistiert werden, gehen sie bei einem Crash verloren. Das ist okay für Cache und Session – nicht für Geschäftsdaten.

6) Mythen aufgeräumt

Drei hartnäckige Aussagen, die oft falsch sind:

Mythen-Sammlung

„NoSQL hat keine Transaktionen."

Falsch. MongoDB unterstützt seit Version 4.0 Multi-Document-Transaktionen mit vollen ACID-Garantien. Auch Redis hat einfache Transaktionen. Trotzdem: nicht so reif und ausgefeilt wie in klassischen SQL-DBs.

„SQL skaliert nicht."

Falsch. Moderne PostgreSQL- oder MySQL-Setups schaffen Millionen Operationen pro Sekunde. Vertikale Skalierung reicht für 95% aller Anwendungen. Horizontale Skalierung gibt es auch (Replikation, Sharding, Citus, CockroachDB) – nur komplexer als bei NoSQL.

„NoSQL ist schneller als SQL."

Kommt drauf an. Für einfache Key-Lookups ja, deutlich. Für komplexe JOINs nein, oft langsamer. Eine indizierte SQL-Query auf eine Tabelle mit Millionen Zeilen ist nicht spürbar langsamer als MongoDB.

„NoSQL ist schema-frei."

Falsch. Es gibt immer ein Schema – nur ist es nicht in der DB definiert, sondern implizit in der Anwendung. Das verlagert das Problem, löst es nicht. Schema-Validation kann in MongoDB explizit aktiviert werden.

„NoSQL ist moderner."

Falsch. NoSQL gibt es seit den 2000ern, SQL seit den 70ern. Beide werden weiterentwickelt. „Modern" sagt nichts über Eignung. PostgreSQL ist heute fortschrittlicher als viele NoSQL-DBs.

„Mit NoSQL spart man Modellierung."

Trügerisch. Du sparst dir das ER-Modell vorab – zahlst aber an anderer Stelle: Embedded vs. Referenced überlegen, Duplikate-Strategie, Denormalisierung. Modellierung verschwindet nicht – sie verschiebt sich.

7) Konkrete Empfehlungen nach Anwendungstyp

Hier eine pragmatische Empfehlung für die häufigsten Anwendungs-Typen, die in der Praxis vorkommen:

Business-Anwendung mit klassischen Daten (CRM, ERP, Buchhaltung, klassisches Backend): SQL (PostgreSQL, MySQL). Optional Redis für Cache und Sessions.
Web-/Mobile-App mit User-generated Content (CMS, Social, Foren): SQL als primäre DB, MongoDB für variable Content-Typen, Redis für Performance.
Online-Shop: SQL für Bestellungen/Buchhaltung, MongoDB optional für Produktkatalog, Redis für Cache und Warenkorb, optional Elasticsearch für Suche.
IoT-/Telemetrie-Daten (Sensoren, Logs, Metriken): spezialisierte Time-Series-DB (InfluxDB, TimescaleDB) oder Wide-Column (Cassandra).
Soziales Netzwerk: Mix aus SQL für Profile/Bestellungen, Graph-DB für Beziehungen, Redis für Feeds.
Real-Time-Analyse / Dashboards: Redis für aktuelle Werte, evtl. ClickHouse oder Druid für Aggregate.
Caching/Sessions/Counter: immer Redis.

Eine fundamental wichtige Empfehlung: fang einfach an. Eine relationale DB plus Redis als Cache reicht für 95% aller Web-Anwendungen unter 100.000 Usern. Komplexere Architekturen sind eine Antwort auf konkrete Probleme – nicht der Standard-Start.

8) IHK-Aufgaben zu diesem Thema

In der Prüfung sind drei Fragetypen typisch, in denen die SQL-NoSQL-Entscheidung vorkommt:

Szenario-Analyse: „Welche Datenbank würden Sie für [Use Case] wählen und warum?" – immer mit Begründung antworten. Stichworte: Datenstruktur, Konsistenz-Anforderungen, Skalierung.
Vor-/Nachteile aufzählen: „Nennen Sie drei Vorteile von NoSQL gegenüber SQL und drei Nachteile." – die Matrix aus Abschnitt 3 liefert die Antworten.
Architektur entwerfen: „Skizzieren Sie eine Architektur, die [Anforderungen] erfüllt." – Polyglot Persistence erwähnen, konkrete Tools nennen.

Sprachliche Klassiker, die du in einer Klausur einbauen kannst und die Punkte bringen: Polyglot Persistence, horizontale vs. vertikale Skalierung, Schema-Flexibilität, eventually consistent, ACID vs. BASE, Trade-off zwischen Konsistenz und Verfügbarkeit. Diese Begriffe in einer Antwort fachlich richtig einzusetzen, ist oft die Differenz zwischen befriedigend und gut.

Zusammenfassung

Die SQL-vs.-NoSQL-Entscheidung ist keine Glaubensfrage, sondern eine Use-Case-Analyse. Fünf Schlüsselfragen: Datenstruktur, ACID-Bedarf, Datenmenge/Last, Abfragetypen, Team-Know-how. Stärken von SQL: feste Schemas, harte ACID-Garantien, komplexe JOINs und Reports, Standards/Tooling, breite Verfügbarkeit von Know-how. Stärken von NoSQL: Schema-Flexibilität, horizontale Skalierung, Sub-Millisekunden-Latenz (Redis), spezialisierte Datenmodelle (Dokument, Graph). Pragmatisches Pattern: Polyglot Persistence – mehrere DBs kombinieren, jede für das was sie kann. Typisches Setup: SQL für Kerngeschäft + Redis für Cache/Sessions + ggf. MongoDB/Elasticsearch/Neo4j für spezielle Anforderungen. Häufige Fehler: NoSQL wegen „Hype" wählen, Schema-Flexibilität als Modellierungs-Ersatz missverstehen, Cache mit primärer DB verwechseln. Standardempfehlung: fang einfach an mit SQL + Redis, ergänze gezielt wenn konkrete Probleme auftauchen. Vorbereitung auf die IHK-Aufgaben in der nächsten und letzten Lektion.