Datenbanktypen - SQL, NoSQL und wann ich welche wirklich wähle

Ein „Datenbanktyp“ ist keine Marke. PostgreSQL und MySQL sind beide relational. MongoDB und Firestore sind beide Dokumentenspeicher. Redis ist eine Key-Value-Engine, die Teams als Cache, Queue und manchmal als gefährlichen Primärspeicher nutzen. Wer eine Datenbank wählt, weil ein Tutorial sie nutzte, wählt Mode. Wer sie wegen der Datenform und der Abfragen wählt, macht Architektur.

Das ist die Karte, die ich nutze, wenn jemand „SQL oder NoSQL?“ fragt - meist die falsche erste Frage. Die erste Frage lautet: was ist eine Zeile (oder ein Dokument, oder ein Knoten) in diesem Produkt, was muss konsistent bleiben, und welche Fragen stellt die App tausendmal am Tag?

1. Was „Typ“ wirklich heißt

Drei Achsen zählen mehr als die Marketingkategorie. Liegen Sie hier falsch, rettet Sie das Logo auf der Box nicht.

• Datenmodell: Tabellen mit Relationen, verschachtelte Dokumente, Keys, Graphen, Zeit-Buckets oder Vektoren.
• Abfragemodell: Joins, Filter nach Feld, Get-by-Key, Graph-Traversal, Zeitbereich - oder „was liegt nah an diesem Embedding?“
• Garantien: ACID-Transaktionen, Eventual Consistency, Einfachheit eines Knotens versus ein Cluster, das Sie um 2 Uhr nachts debuggen.

2. Relational (SQL) - Standard für Geld und Relationen

PostgreSQL, MySQL, SQLite. Zeilen in Tabellen, Fremdschlüssel, Joins, Migrationen, ACID-Transaktionen. Das ist weiter das richtige Zuhause für die meisten Webprodukte: Nutzer, Arbeitsbereiche, Rollen, Bestellungen, Rechnungen, Buchungen, Bestand. Wenn eine Zeile existieren muss, weil eine andere existiert, oder eine Abbuchung nicht zweimal laufen darf, wollen Sie eine relationale Engine - kein JSON-Blob und ein Gebet.

PostgreSQL ist mein Standard 2026: JSONB, wenn ein Feld wirklich schemalos ist, Full-Text für kleine Suche, pgvector wenn RAG später kommt. Sie kommen weit, bevor Sie eine zweite Datenbank „brauchen“. SQLite ist unterschätzt für Local-First, CLIs und winzige Produkte. MySQL ist in Ordnung, wenn das Team es schon betreibt - von null starte ich dort nicht.

• Wählen Sie SQL, wenn Integrität, Reports mit Joins und „wer hat in diesem Arbeitsbereich wofür bezahlt“ die Aufgabe sind.
• Wählen Sie SQL nicht, weil es „Enterprise“ ist. Wählen Sie es, weil die Domain ein Graph von Fakten ist, die zusammen wahr bleiben müssen.

3. Dokumentdatenbanken - flexible Objekte, teure Relationen

MongoDB, CouchDB, Firestore, DynamoDB im Dokumentmodus. Ein Dokument ist ein JSON-Baum. Das passt, wenn die Arbeitseinheit ein Objekt mit verschachtelten Teilen ist, die immer zusammen geladen werden: ein CMS-Artikel, ein Produkt mit einem unordentlichen Attributbeutel, ein Nutzerprofil, das Sie immer ganz holen.

Die Falle: Sie haben trotzdem Nutzer, Arbeitsbereiche und Rechnungen. Sie erfinden Joins in der App neu, verlieren Multi-Dokument-Transaktionen (oder zahlen dafür) und verbringen ein Jahr damit, Uniqueness-Regeln nachzurüsten, die eine relationale Engine am ersten Tag geliefert hätte. Ich nutze einen Dokumentenspeicher, wenn das Produkt content-förmig ist und das Zugriffsmuster „Blob per Id laden“ lautet. Nicht, weil das Frontend JSON spricht. Postgres JSONB spricht schon JSON.

4. Key-Value - Redis und Freunde

Redis, Memcached, DynamoDB als reiner Key-Value-Store. Get, Set, Expire. Optional Listen, Sets, Pub/Sub. Hier lebt nicht die Buchhaltung der Wahrheit. Es ist die schnelle Schicht daneben.

• Gut: Sessions, Rate Limits, Feature Flags, Idempotenz-Keys, Cache teurer Reads, kurzlebige Sperren.
• Schlecht: die einzige Kopie von Bestellungen, Nutzern oder Rechten. Ein Flush oder eine Eviction-Policy - und Sie haben einen Support-Albtraum.

5. Wide-Column - wenn die Writes nie aufhören

Cassandra, Scylla, Bigtable. Partition nach Key, viel schreiben, nach diesem Key lesen, und akzeptieren, dass Ad-hoc-SQL nicht der Punkt ist. Richtig für Telemetrie in riesigem Maßstab, Inbox-Feeds, write-lastige Multi-Region-Last. Falsch für ein Booking-SaaS mit zwölf Tabellen. Wenn Sie noch keine Zahl wie „Millionen Writes pro Sekunde“ haben, überspringen Sie die Kategorie. Die Betriebskosten des Clusters sind das Produkt.

6. Graph - wenn die Frage die Verbindung ist

Neo4j, Amazon Neptune und - für kleine Graphen - SQL mit rekursiven CTEs. Eine Graph-Engine lohnt, wenn das Produkt das Netzwerk ist: Empfehlungen, Betrugsringe, Org-Charts, Rechtevererbung, „wer ist zwei Hops von diesem Lieferanten.“ Nicht, weil Sie Kästchen und Pfeile ans Whiteboard gemalt haben. Fast jede Domain hat Relationen. Relationale Datenbanken modellieren Relationen schon. Graph-Engines verdienen ihren Platz, wenn Traversal-Tiefe die Query ist - nicht das Schema-Diagramm.

7. Time-Series - Metriken, Sensoren, Events über die Zeit

InfluxDB, TimescaleDB, Prometheus für Ops, ClickHouse für analytics-förmige Events. Wenn jede Zeile „dieses Gerät oder diese Metrik zu diesem Timestamp“ ist, tut ein allgemeines OLTP-Schema weh: zu viele Inserts, Range-Scans, Retention. TimescaleDB ist attraktiv, weil es PostgreSQL bleibt - dieselben Backups, dasselbe SQL, Hypertables für den Hot Path. ClickHouse ist Analytics, nicht die Checkout-Transaktion. Schütten Sie Ihre Bestelltabelle nicht in eine Time-Series-Engine, nur weil created_at existiert.

8. Vektor - Embeddings, keine zweite maßgebliche Quelle

Pinecone, Qdrant, Weaviate und pgvector in Postgres. Sie speichern Vektoren, um zu fragen „welcher Text liegt nah an dieser Frage?“ Das ist RAG, semantische Suche, Duplikaterkennung. Artikel, Preis, Nutzer leben weiter in der operativen Datenbank. Der Vektorindex ist ein abgeleiteter Index, wie Suche. Bauen Sie ihn neu. Lassen Sie Checkout oder Rechte nicht davon abhängen.

2026 ergänze ich zuerst pgvector in Postgres. Eine eigene Vektordatenbank, wenn Korpusgröße und QPS ein weiteres bewegliches Teil rechtfertigen - nicht weil ein Pitch Deck „AI-native“ gesagt hat.

9. Suche ist keine maßgebliche Datenquelle

Elasticsearch, OpenSearch, Typesense, Meilisearch. Full-Text, Tippfehler, Facetten, Ranking. Bauen Sie aus der maßgeblichen Quelle neu. Lassen Sie Checkout, Bestand oder Rechte nie nur von einem Index abhängen, der nach einem gescheiterten Reindex driften kann. Postgres-Full-Text reicht für viele kleine Kataloge. Eine Such-Engine, wenn Nutzer unordentliche Queries tippen und Sie Relevanz brauchen - nicht wenn Ihnen SQL langweilig ist.

10. Wie ich wirklich wähle

Ich lasse die Filter in dieser Reihenfolge laufen. Der Stack kommt nach den Antworten, nicht vor der Vergleichstabelle.

• Was ist die Einheit der Konsistenz? Wenn Geld oder Bestand sich bewegt: SQL mit Transaktionen. Nicht „Duplikate flicken wir in der App.“
• Was ist die Hot Query? Per Id, Join, Full-Text, Ähnlichkeit, Zeitbereich oder Graph-Hop? Die Engine an diese Form koppeln.
• Wer betreibt das um 2 Uhr nachts? Ein gemanagtes Postgres schlägt ein clevers Cluster, das niemand im Team debuggen kann.
• Reicht eine Engine für 80%? Postgres plus Redis deckt die meisten Webprodukte ab, die ich wirklich live nehme.

Ein 2026-Standard, mit dem ich wirklich starten würde

Solange das Datenmodell nicht vom ersten Tag an einen Spezialisten erzwingt, würde ich mit diesem Stack öffnen - und ihn nicht erweitern, bis ein gemessener Engpass erscheint, nicht ein Blogpost.

• PostgreSQL als maßgebliche Datenquelle. JSONB, wo ein Feld wirklich schemalos ist. pgvector, wenn RAG ein echtes Feature ist, keine Folie.
• Redis für Cache, Sessions, Rate Limits und leichte Queues. Nicht für Bestellungen.
• Object Storage für Dateien. Eine Such-Engine erst, wenn LIKE und Postgres-FTS nicht mehr reichen.

Der Typ ist die Form der Aufgabe

SQL vs NoSQL war ein Streit der 2010er. Die nützliche Frage 2026 lautet: welches Datenmodell passt zur Aufgabe, und wie wenige Systeme können Sie gut betreiben? Starten Sie mit einer relationalen maßgeblichen Quelle. Ergänzen Sie einen Spezialspeicher, wenn die Query-Form wirklich anders ist - Cache, Suche, Vektoren, Time-Series. Hybrid ist normal. Fünf Datenbanken am Tag eins eines MVP - so stirbt das Experiment.