Datenbanken im Vergleich

Kaum eine Architekturentscheidung wirkt so lange nach wie die Wahl der Datenbank. Programmiersprachen lassen sich Modul für Modul austauschen, Frameworks werden migriert, Infrastruktur wandert in die Cloud und wieder zurück. Die Datenbank aber bleibt. Sie trägt die Daten, und Daten überleben in den meisten Organisationen jede einzelne Anwendung, die je auf sie zugegriffen hat.

Umso bemerkenswerter ist, wie diese Entscheidung in der Praxis häufig zustande kommt. Nicht selten fällt die Wahl auf das System, das im Team bereits bekannt ist, mit dem der letzte Dienst gebaut wurde oder das in der Organisation ohnehin lizenziert ist. Die Frage, ob das vorliegende Problem überhaupt zu diesem System passt, wird dabei oft gar nicht erst gestellt. Das muss nicht falsch sein, wie sich noch zeigen wird. Problematisch ist nur, wenn die Entscheidung unbewusst fällt.

Vom Universalwerkzeug zur Spezialisierung

Über Jahrzehnte galt die relationale Datenbank als selbstverständliche Grundlage nahezu jeder Anwendung. Ein einziges System übernahm Transaktionsdaten, Auswertungen, Zwischenspeicher und Suchfunktion gleichermaßen. Diese Selbstverständlichkeit ist ins Wanken geraten. Mit dem Aufstieg des Internets auf seine heutige Größe stießen relationale Datenbanken, die auf einem einzelnen Server betrieben werden, an ihre Grenzen, und es entstand eine ganze Generation spezialisierter Systeme, die unter dem Sammelbegriff NoSQL bekannt wurde. Der Begriff steht dabei weniger für eine Ablehnung der Abfragesprache SQL als für die Abkehr von der Annahme, ein einziges Datenbankmodell könne alle Probleme gleich gut lösen.

Parallel dazu veränderte sich die Softwarearchitektur selbst. Anwendungen werden heute vielfach als Verbund kleinerer, über Schnittstellen kommunizierender Dienste gebaut, in der Fachsprache Microservices genannt. In einer solchen Architektur kann jeder Dienst ohne großen technischen Mehraufwand die Datenbank nutzen, die zu seiner Aufgabe passt. Für diesen Ansatz hat sich der von Martin Fowler geprägte Begriff Polyglot Persistence etabliert, sinngemäß die Mehrsprachigkeit in der Datenhaltung: ein Graphsystem für stark vernetzte Daten, eine In-Memory-Datenbank für Zwischenergebnisse, ein relationales System für flexible Auswertungen.

Die Vielfalt an verfügbaren Systemen ist Chance und Belastung zugleich. Wer sie kennt, kann Probleme mit dem jeweils passenden Werkzeug lösen. Wer sie ignoriert, riskiert, ein System jahrelang gegen seine eigentlichen Stärken zu betreiben. Wer sie überschätzt, handelt sich mit jedem zusätzlichen System neuen Betriebsaufwand ein. Der Artikel gibt deshalb zunächst einen Überblick über die wichtigsten Datenbankmodelle, entwickelt daraus ein Entscheidungsraster und stellt anschließend die Gegenposition vor, denn es gibt gewichtige Argumente dafür, trotz allem bei der bekannten Technologie zu bleiben.

Die Modelle im Überblick

Drei Begriffe tauchen im Folgenden wiederholt auf und seien deshalb vorab erklärt. ACID (Atomicity, Consistency, Isolation, Durability) bezeichnet vier Garantien, die sicherstellen, dass eine Datenbanktransaktion entweder vollständig oder gar nicht ausgeführt wird und die Daten dabei konsistent bleiben, selbst wenn währenddessen ein Systemfehler auftritt. Das CAP-Theorem beschreibt die Erkenntnis, dass eine verteilte Datenbank während einer Netzwerkstörung nicht gleichzeitig vollständig konsistent und vollständig verfügbar sein kann, auf eine der beiden Eigenschaften muss in diesem Moment verzichtet werden. Sharding schließlich meint die Aufteilung der Daten auf mehrere Server, damit eine Datenbank über die Kapazität einer einzelnen Maschine hinauswachsen kann.

Die folgende Übersicht umfasst zwölf Datenbankmodelle: die sieben klassischen sowie fünf weitere, die sich in den vergangenen Jahren als eigenständig etabliert haben und in keiner aktuellen Bestandsaufnahme fehlen sollten.

Zwei Begriffe aus der Tabelle verdienen eine gesonderte Erläuterung. Das Gegensatzpaar Online Transaction Processing (OLTP) und Online Analytical Processing (OLAP) unterscheidet zwei grundverschiedene Arbeitslasten: OLTP steht für die klassische transaktionale Verarbeitung einzelner Vorgänge, etwa einer Bestellung oder Kontobuchung, während OLAP die analytische Auswertung großer, meist historischer Datenmengen bezeichnet, wie sie in Berichten und Dashboards zusammenläuft. Embeddings wiederum sind numerische Vektoren, die die Bedeutung eines Textes, Bildes oder anderen Inhalts so abbilden, dass inhaltlich Ähnliches auch mathematisch nah beieinanderliegt. Erst diese Darstellung macht eine Ähnlichkeitssuche berechenbar, weshalb Vektordatenbanken zur Standardinfrastruktur von KI-Anwendungen geworden sind.

So übersichtlich eine solche Tabelle wirkt, die tatsächliche Entwicklung verläuft in die Gegenrichtung: Die Grenzen zwischen den Modellen verschwimmen. PostgreSQL etwa verarbeitet inzwischen auch JSON-Dokumente, bietet eine eingebaute Volltextsuche und lässt sich per Erweiterung um Vektorsuche ergänzen. Die scharfe Trennung zwischen relationalen und dokumentbasierten Systemen, die vor gut einem Jahrzehnt die NoSQL-Bewegung prägte, ist damit heute deutlich weniger scharf, als es die Einteilung nahelegt. Für die Auswahl bedeutet das: Die Frage lautet immer seltener, welches Modell ein System vertritt, und immer häufiger, welche Arbeitslast es in welcher Qualität abdeckt.

Das Entscheidungsraster

Eine Übersicht allein trifft jedoch keine Entscheidung. Die folgenden Kriterien helfen dabei, aus der Modellvielfalt eine begründete Auswahl abzuleiten. Die entscheidenden Fragen richten sich dabei zunächst nicht an ein konkretes Produkt, sondern an das Problem, das gelöst werden soll.

Konsistenz: Wie aktuell muss eine Antwort sein

Die erste und folgenreichste Frage betrifft das Konsistenzmodell. Manche Anwendungen setzen zwingend voraus, dass jede Leseoperation den zuletzt geschriebenen Stand widerspiegelt. Eine Kontobuchung, die kurzzeitig doppelt ausgeführt werden kann, ist kein Schönheitsfehler, sondern ein Geschäftsrisiko. Systeme wie PostgreSQL oder HBase garantieren diese starke Konsistenz. Bei anderen Anwendungen ist es weniger problematisch, wenn eine Änderung erst mit einigen Sekunden Verzögerung überall sichtbar wird, in der Fachsprache Eventual Consistency genannt. Wer diese Verzögerung akzeptiert, gewinnt im Gegenzug Verfügbarkeit und Ausfalltoleranz, wie es etwa CouchDB oder Cassandra anbieten. Cassandra erlaubt es sogar, den Konsistenzgrad für jede einzelne Anfrage festzulegen. Hinter dieser Abwägung steht das bereits erwähnte CAP-Theorem: Während einer Netzwerkstörung kann ein verteiltes System Konsistenz und Verfügbarkeit nicht gleichzeitig in vollem Umfang garantieren. Die Frage ist also nicht, ob dieser Kompromiss eingegangen wird, sondern wo.

Skalierungsrichtung: Ein größerer Server oder viele kleine

Die zweite Frage lautet, in welche Richtung eine Anwendung voraussichtlich wächst. Vertikale Skalierung bedeutet, einen einzelnen Server mit mehr Rechenleistung, Arbeitsspeicher und Speicherplatz auszustatten. Das ist der klassische Weg relationaler Systeme und reicht für viele Anwendungen länger, als gemeinhin angenommen wird. Horizontale Skalierung bedeutet dagegen, die Last auf zusätzliche Server zu verteilen. Systeme wie Cassandra, HBase, MongoDB oder DynamoDB sind von Grund auf dafür gebaut; bei Cassandra wächst der Durchsatz nahezu linear mit der Zahl der Knoten. Die NewSQL-Systeme um CockroachDB und TiDB versprechen beides zugleich, erkaufen die Kombination aus ACID-Garantien und horizontaler Verteilung jedoch mit höheren Antwortzeiten, da sich die beteiligten Knoten bei jeder Transaktion über einen Konsensmechanismus abstimmen müssen.

Abfragemuster: Bekannte Schlüssel oder offene Fragen

Die dritte Frage betrifft die Art der Zugriffe. Am einen Ende des Spektrums stehen Anwendungen, die Daten ausschließlich über einen bereits bekannten Schlüssel abrufen. Ein typisches Beispiel sind Sessions: Der Browser schickt die Session-ID bei jedem Aufruf mit, und die Anwendung muss lediglich den zu genau dieser ID gehörenden Datensatz laden. Es wird weder gefiltert noch verknüpft noch gesucht, weshalb ein Schlüssel-Wert-Speicher ausreicht und die Abfragefähigkeiten eines komplexeren Systems ungenutzt blieben. Am anderen Ende stehen Auswertungen, deren Fragestellungen bei der Einführung noch gar nicht feststehen. Hier spielt das relationale Modell mit seiner freien Kombinierbarkeit von Tabellen seine historische Stärke aus. Dazwischen liegen Spezialfälle, die eigene Modelle rechtfertigen: Volltextsuche mit Relevanzbewertung gehört in einen Suchindex wie Elasticsearch oder OpenSearch, aggregierende Auswertungen über Milliarden von Zeilen in ein analytisches System wie ClickHouse, und die Traversierung vielstufiger Beziehungen, etwa die Frage nach den Freunden der Freunde, in ein Graphsystem, da relationale Datenbanken mit jeder weiteren Beziehungsebene messbar langsamer werden.

Betriebsaufwand: Wer kümmert sich um das System

Die vierte Frage wird am häufigsten unterschätzt, weil sie nicht die Software betrifft, sondern die Organisation dahinter. Jedes selbst betriebene Datenbanksystem verlangt Wissen über Installation, Härtung und Zugriffsschutz, Aktualisierung, Datensicherung und Wiederherstellung. Ein Hadoop-basiertes System wie HBase gilt selbst unter erfahrenen Administratoren als anspruchsvoll, und auch ein Suchindex entfaltet seinen Betriebsaufwand erst ab einer gewissen Clustergröße in voller Breite. Zwischen dem vollständigen Eigenbetrieb und dem Verzicht auf eigene Infrastruktur gibt es allerdings ein breites Mittelfeld: Nahezu jedes verbreitete System ist heute auch als verwalteter Dienst (Managed Service) verfügbar, etwa PostgreSQL über Amazon RDS oder Azure Database, MongoDB über Atlas oder Redis über Redis Cloud. Der Betriebsaufwand lässt sich damit auch für klassische Systeme deutlich reduzieren, gegen Aufpreis und ein gewisses Maß an Anbieterbindung. Dienste wie DynamoDB gehen noch einen Schritt weiter und existieren ausschließlich als verwalteter Dienst, wodurch der Administrationsaufwand fast vollständig entfällt, die Bindung an Anbieter und Preismodell dafür am stärksten ausfällt.

Teamwissen und Ökosystem: Die Umgebung entscheidet mit

Die fünfte Frage schließlich richtet sich auf das Umfeld einer Technologie. Eine große Community bedeutet dokumentierte Lösungen für nahezu jedes Problem, das im Betrieb auftreten kann. Ein reifes Ökosystem bedeutet ausgereifte Treiber, Werkzeuge und Integrationen. Und ein verbreitetes System bedeutet, dass sich Personal dafür finden lässt. Diese Faktoren tauchen in keinem technischen Benchmark auf, entscheiden im Alltag aber oft stärker über Erfolg und Misserfolg als die reine Leistungsfähigkeit. Genau an dieser Stelle beginnt allerdings auch die Gegenposition zur gesamten bisherigen Argumentation: Wenn Vertrautheit und Verbreitung derart schwer wiegen, spricht dann nicht vieles dafür, schlicht bei der bekannten Technologie zu bleiben?

Die Gegenposition: Warum das Bekannte oft die klügere Wahl ist

Die bisherigen Abschnitte haben eine deutliche Empfehlung entwickelt: Wer die Datenbankmodelle kennt und anhand klarer Kriterien auswählt, trifft bessere Entscheidungen als jemand, der reflexhaft zum vertrauten System greift. Diese Empfehlung hat jedoch eine gewichtige Gegenposition, und wer sie ignoriert, macht denselben Fehler in umgekehrter Richtung.

Die wohl bekannteste Formulierung der Gegenposition stammt von dem Softwarearchitekten Dan McKinley, der jahrelang die Architektur der Handelsplattform Etsy mitverantwortete. Sein Essay mit dem programmatischen Titel Choose Boring Technology führt das Bild der Innovation Tokens ein: Jede Organisation verfügt demnach nur über eine kleine Anzahl an Wagnissen, die sie sich gleichzeitig leisten kann. Jede neue, im Team noch nicht verankerte Technologie mit steiler Lernkurve verbraucht eines dieser Tokens, unabhängig davon, wie gut sie zum Problem passt. Wer seine Tokens für eine exotische Datenbank ausgibt, hat sie nicht mehr für das eigentliche Produkt zur Verfügung.

McKinleys zweites Argument wiegt womöglich schwerer. Der Wert einer etablierten, im landläufigen Sinne langweiligen Technologie liegt weniger in dem, was sie kann, als in dem, was über sie bekannt ist: ihre Fehlermodi. Verhält sich PostgreSQL unter Last unerwartet, existiert mit hoher Wahrscheinlichkeit bereits eine dokumentierte Erklärung samt erprobtem Lösungsweg. Bei einem jungen Spezialsystem muss dieses Wissen erst erarbeitet werden, im ungünstigsten Fall nachts, unter Produktionsdruck. Hinzu kommen nüchterne organisatorische Faktoren: Für verbreitete Systeme lässt sich Personal finden, und der Betrieb hängt nicht an einer einzelnen Person, die sich in ein Nischensystem eingearbeitet hat. Die Formel vom besten Werkzeug für den jeweiligen Job greift aus dieser Sicht zu kurz, weil sie jedes Problem isoliert betrachtet, nicht aber die Organisation, die alle diese Werkzeuge dauerhaft beherrschen muss.

Auch der Ansatz der Polyglot Persistence hat seinerseits einen Preis, der in Architekturdiagrammen nicht sichtbar wird. Jedes zusätzliche Datenbanksystem bringt ein eigenes Sicherungskonzept mit, ein eigenes Monitoring, eigene Update- und Sicherheitszyklen und ein eigenes Fachvokabular, das im Team präsent gehalten werden muss. Fünf technisch jeweils perfekt passende, aber unterschiedliche Systeme sind für ein kleines Team häufig schwerer zu betreiben als ein einziges, das vier von fünf Anwendungsfällen lediglich gut genug abdeckt. Die Entscheidung für Vielfalt verdient deshalb dieselbe Sorgfalt wie die Entscheidung dagegen. Nicht weil Vielfalt falsch wäre, sondern weil ihr Nutzen gegen einen sehr realen Betriebsaufwand abgewogen werden muss, der mit jedem System wächst.

Wo sich beide Schulen treffen

Dass die beiden Denkschulen keine unvereinbaren Lager sind, zeigt eine aktuelle Entwicklung aus dem Umfeld künstlicher Intelligenz. Anwendungen, die auf Ähnlichkeitssuche in sogenannten Embeddings angewiesen sind, etwa beim Verfahren Retrieval-Augmented-Generation, bei dem ein Sprachmodell vor der Antwort passende Dokumente aus einem Datenbestand erhält, legten zunächst die Einführung einer dedizierten Vektordatenbank nahe. Tatsächlich zeichnet sich derzeit eine Gegenbewegung ab: Viele Entwicklungsteams, die solche KI-Funktionen in bestehende Anwendungen integrieren, erweitern stattdessen die ohnehin vorhandene PostgreSQL-Instanz um die Erweiterung pgvector und behalten damit die bekannte Infrastruktur, die bekannten Sicherungsstrategien und den bekannten Zugriffsschutz bei. Bis in den Bereich von zehn bis zwanzig Millionen Vektoren gilt dieser Weg inzwischen als produktionsreif, mit Erweiterungen wie pgvectorscale verschiebt sich die Grenze weiter nach oben. Erst bei größeren Datenmengen oder sehr strengen Latenzanforderungen liefern dedizierte Systeme in Benchmarks weiterhin spürbar konstantere Antwortzeiten.

Das Beispiel führt beide Positionen auf denselben Punkt: Die richtige Technologie ist nicht zwangsläufig die speziellste verfügbare. Mitunter ist sie eine vertraute, gezielt erweiterte. Wer so entscheidet, folgt gleichzeitig dem Rat, das passende Werkzeug zu wählen, und dem Rat, bei der langweiligen Technologie zu bleiben.

Fazit

Am Ende steht keine Regel, sondern eine Haltung. Die Wahl einer Datenbank verdient mehr Aufmerksamkeit, als ihr im Projektalltag üblicherweise zukommt, denn sie gehört zu den Entscheidungen mit der längsten Wirkung. Wer die grundlegenden Modelle kennt und anhand von Konsistenzanforderungen, Skalierungsrichtung, Abfragemustern und Betriebsaufwand auswählt, wird seltener eine Wahl treffen, die sich später als schmerzhaft korrekturbedürftig erweist. Zugleich ist Vertrautheit kein Makel, sondern ein legitimes Entscheidungskriterium mit messbarem Wert: bekannte Fehlermodi, verfügbares Personal, geteiltes Wissen im Team. Die eigentliche Kompetenz liegt nicht darin, stets die exotischste Lösung zu wählen, und ebenso wenig darin, jede Neuerung abzuwehren. Sie liegt darin, die Entscheidung überhaupt bewusst zu treffen, sie begründen zu können und sie auch dann noch zu vertreten, wenn sie nach einigen Jahren auf dem Prüfstand steht.