SQL oder NoSQL?

Kaum eine Entscheidung prägt ein System so lange wie die Wahl der Datenbank. Code lässt sich umschreiben, Server lassen sich austauschen, aber Daten ziehen ungern um. Umso erstaunlicher ist, wie oft diese Entscheidung aus dem Bauch heraus fällt: „NoSQL skaliert besser“, „MongoDB ist flexibler“, „SQL ist veraltet“. Solche Schlagworte helfen nicht weiter. Diese Lektion zeigt, welche Arten von Datenbanken es gibt, wofür sie sich eignen und wie man eine begründete Entscheidung trifft.

1. Relationale Datenbanken

Relationale Datenbanken sind seit Jahrzehnten der Standard für Geschäftsdaten, und das aus gutem Grund. Die meisten Anwendungen verwalten Dinge mit Beziehungen: Kunden haben Buchungen, Buchungen gehören zu Terminen, Termine zu Mitarbeitern. Solche Beziehungen lassen sich in Tabellen natürlich abbilden. Vor allem aber setzen relationale Datenbanken die Invarianten durch, die im ersten Modul so wichtig waren: Eine eindeutige Regel verhindert Doppelbuchungen, ein Fremdschlüssel verhindert Buchungen für nicht existierende Kunden, eine Transaktion sorgt dafür, dass Bestellung und Zahlung entweder beide gespeichert werden oder keines von beiden.

PostgreSQL hat sich in den letzten Jahren zu einer Art Universalwerkzeug entwickelt. Neben klassischen Tabellen kann es halbstrukturierte Daten als JSON speichern und effizient durchsuchen, bietet Volltextsuche, geografische Abfragen mit PostGIS, Zeitreihen mit TimescaleDB und Vektorsuche für KI-Anwendungen mit pgvector. Für die allermeisten Anwendungen gilt deshalb: Starten Sie mit PostgreSQL und ergänzen Sie spezialisierte Systeme erst, wenn es einen klaren Grund gibt.

2. Nicht-relationale Datenbanken

Nicht-relationale Datenbanken, oft unter dem Begriff NoSQL zusammengefasst, sind keine Konkurrenz zu relationalen, sondern Spezialwerkzeuge. Jede ist für bestimmte Zugriffsmuster optimiert und verzichtet dafür auf etwas anderes: Schlüssel-Wert-Speicher auf komplexe Abfragen, Dokumentdatenbanken oft auf Beziehungen und strenge Regeln, spaltenorientierte Datenbanken auf schnelle Einzeländerungen. Das Versprechen, NoSQL skaliere automatisch besser, trifft heute nur noch eingeschränkt zu: Relationale Datenbanken bewältigen auf moderner Hardware sehr große Datenmengen, und die meisten Anwendungen erreichen ihre Grenzen nie.

3. Entscheiden nach Zugriffsmustern

Die richtige Frage lautet nicht „SQL oder NoSQL?“, sondern: Wie werden die Daten gelesen und geschrieben, welche Regeln müssen gelten, und wie groß werden sie? Üben Sie die Zuordnung:

4. Mehrere Datenbanken, eine Wahrheit

Größere Systeme nutzen oft mehrere Datenspeicher: PostgreSQL für Geschäftsdaten, Redis als Cache, eine Suchmaschine für die Volltextsuche, einen Objektspeicher für Dateien. Man nennt das Polyglot Persistence. Das ist sinnvoll, bringt aber eine neue Herausforderung mit sich: Die Daten müssen synchron gehalten werden. Wenn ein Produkt in PostgreSQL geändert wird, muss auch der Suchindex aktualisiert und der Cache geleert werden. Geschieht das nicht zuverlässig, zeigt die Suche veraltete Preise oder gelöschte Produkte.

Die wichtigste Regel dafür lautet: Es gibt genau eine Quelle der Wahrheit, meist die relationale Datenbank. Alle anderen Speicher sind abgeleitete Kopien, die sich jederzeit aus der Quelle neu aufbauen lassen. Änderungen fließen immer von der Quelle zu den Kopien, nie umgekehrt. Für die zuverlässige Übertragung gibt es bewährte Muster wie das Transactional Outbox Pattern, bei dem eine Änderung und eine Nachricht über diese Änderung in derselben Transaktion gespeichert werden; ein separater Prozess liest die Nachrichten und aktualisiert die abgeleiteten Speicher. Das Modul Skalierung vertieft diese Muster.

5. Datenmodellierung

Wichtiger als die Wahl der Datenbank ist oft die Qualität des Datenmodells. Ein gutes Modell bildet die fachlichen Begriffe und Regeln klar ab: Welche Entitäten gibt es, welche Beziehungen, welche Eigenschaften sind Pflicht, welche Kombinationen müssen eindeutig sein? Für relationale Datenbanken hat sich die Normalisierung bewährt: Jede Information wird nur an einer Stelle gespeichert, damit keine Widersprüche entstehen. Für Leseleistung wird manchmal gezielt denormalisiert, etwa indem ein häufig benötigter Zähler zusätzlich gespeichert wird. Diese Abweichungen sollten bewusst und dokumentiert erfolgen.

Ein praktischer Rat für die Arbeit mit PostgreSQL: Nutzen Sie die Regeln der Datenbank. Pflichtfelder, eindeutige Regeln, Fremdschlüssel und Prüfbedingungen sind kein lästiges Beiwerk, sondern die zuverlässigste Verteidigungslinie gegen fehlerhafte Daten. Anwendungscode kann Fehler haben, mehrere Anwendungen können auf dieselben Daten zugreifen, und bei Nebenläufigkeit versagen Prüfungen im Code. Was die Datenbank selbst durchsetzt, gilt immer. Und schließlich: Änderungen am Schema erfolgen über versionierte Migrationen, die im Code mitverwaltet werden – nie von Hand in der Produktivdatenbank.

Für die folgenden Lektionen dieses Moduls bildet PostgreSQL den roten Faden: Transaktionen und Isolation, Indizes, Replikation und Partitionierung, Konsistenz in verteilten Systemen sowie die Frage, wo Dateien und Suchindizes hingehören.

6. Ein Beispiel für eine Entscheidung

Wie eine begründete Datenbankentscheidung aussieht, zeigt eine Sprachlern-App. Sie verwaltet Nutzer, Kurse, Lektionen, Lernfortschritt, Abonnements, hochgeladene Audioaufnahmen und eine KI-gestützte Suche in Lerninhalten. Die Kerndaten – Nutzer, Kurse, Fortschritt, Abos – haben klare Beziehungen und Regeln: Ein Fortschritt gehört zu genau einem Nutzer und einer Lektion, ein Abo darf nicht doppelt aktiv sein. Sie gehören in PostgreSQL. Die Audioaufnahmen sind große Dateien und gehören in einen Objektspeicher, in der Datenbank steht nur der Verweis. Für die KI-Suche werden Textabschnitte als Vektoren gespeichert; bei einigen zehntausend Abschnitten genügt pgvector in derselben PostgreSQL-Datenbank. Sitzungen und kurzlebige Zwischenergebnisse landen in Redis.

Das Ergebnis sind drei Speicher mit klaren Rollen statt eines bunten Zoos verschiedener Datenbanken. Die Begründung lässt sich in wenigen Sätzen festhalten, und jede Entscheidung kann überprüft werden, wenn sich Anforderungen ändern. Wächst die Suche später auf Millionen Abschnitte oder braucht sie Funktionen, die pgvector nicht bietet, lässt sich eine spezialisierte Vektordatenbank ergänzen – als abgeleiteter Speicher, der aus PostgreSQL gespeist wird. Die Quelle der Wahrheit bleibt dabei unverändert, und der Umbau betrifft nur einen klar abgegrenzten Teil des Systems.

Halten Sie solche Entscheidungen schriftlich fest, am besten mit Datum, Begründung und den Bedingungen, unter denen Sie sie überdenken würden. So lässt sich später nachvollziehen, warum das System so gebaut ist, und neue Kollegen verstehen schneller, welche Rolle jeder Speicher spielt.

Ein letzter Rat: Unterschätzen Sie nicht, wie viel eine einzige gut betriebene Datenbank leisten kann. Viele Teams fügen zu früh weitere Systeme hinzu und handeln sich damit Synchronisationsprobleme ein, die sie ohne Not nie gehabt hätten.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.