Wie LLMs Produktanforderungen auf Datenbankauswahl abbilden, was sie übersehen, und eine praktische Checkliste, um Empfehlungen zu prüfen, bevor Sie sich für einen Stack entscheiden.
Teams bitten LLMs um Datenbankempfehlungen aus dem gleichen Grund, aus dem sie sie E-Mails formulieren oder Spezifikationen zusammenfassen lassen: Es geht schneller als bei null anzufangen. Wenn du vor einer Handvoll Optionen stehst—PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse und andere—kann ein LLM schnell eine Shortlist erstellen, Trade-offs skizzieren und einen „gut genug“-Startpunkt für die Teamdiskussion liefern.
Richtig eingesetzt zwingt das auch dazu, Anforderungen zu formulieren, die sonst vage geblieben wären.
Kurz gesagt: Du beschreibst das Produkt („ein Marktplatz mit Listings und Chat“), die Daten („Nutzer, Bestellungen, Nachrichten“) und die Einschränkungen („muss auf 1M Nutzer skalieren, braucht schnelle Suche, geringer Betriebsaufwand“). Das LLM bildet diese Bedürfnisse dann auf gängige Architekturmuster ab:
Diese Zuordnung kann früh sehr nützlich sein, besonders wenn die Alternative ein leeres Blatt ist.
Eine LLM-Empfehlung sollte als Hypothese und nicht als Architektururteil behandelt werden. Sie kann dir helfen:
Aber sie kann ohne sorgfältige Eingaben nicht deine reale Traffic-Form, Datenwachstum, Teamfähigkeiten, Anbieterrestriktionen oder Betriebstoleranz kennen—und selbst dann führt sie keine Produktionstests durch.
LLMs fallen in vorhersehbare Fallen: Sie stützen sich auf populäre Faustregeln, raten fehlende Details, übersehen Transaktionen und Konsistenzanforderungen, nehmen Performance ohne Benchmarks an und unterschätzen Kosten und betrieblichen Aufwand.
Der Rest dieses Artikels zerlegt diese Fehlermodi und endet mit einer praktischen Checkliste, um Empfehlungen eines LLMs zu validieren, bevor du dich verpflichtest.
Wenn du ein LLM bittest, „eine Datenbank zu empfehlen“, bewertet es Datenbanken nicht so wie ein Ingenieur. Es wandelt deinen Prompt in inferierte Anforderungen um, vergleicht diese mit Mustern aus der Trainingsdatenbasis und erzeugt dann eine Antwort, die wie eine Entscheidung wirkt.
Die Eingaben sind nicht nur die expliziten Details, die du lieferst (Traffic, Datengröße, Konsistenzbedarf). Das Modell nutzt außerdem:
Weil viele Prompts unvollständig sind, füllt das Modell Lücken oft mit impliziten Annahmen—manchmal richtig, manchmal nicht.
Die meisten Antworten landen auf drei Ebenen:
Das Ergebnis kann sich wie eine klare Empfehlung anfühlen, ist aber oft eine strukturierte Zusammenfassung konventioneller Optionen.
LLMs generalisieren aus Beispielen; sie führen keine Lasttests für deinen Workload durch, inspizieren dein Schema oder benchmarken Queries. Wenn Trainingsdaten stark „High Scale“ mit „NoSQL“ assoziieren, bekommst du diese Antwort möglicherweise auch dann, wenn ein gut getuntes SQL-System besser passt.
Selbstbewusste Formulierungen sind Stil, keine Messung. Wenn das Modell nicht explizit Annahmen nennt ("Ich gehe davon aus, dass hauptsächlich append-only Writes vorliegen und eventual consistency akzeptabel ist"), kann die Sicherheit die wirkliche Unsicherheit verbergen: fehlende Inputs und ungetestete Performance-Aussagen.
Wenn Menschen sagen „Wähle eine Datenbank basierend auf Produktanforderungen“, meinen sie oft mehr als „wir speichern Nutzer und Bestellungen“. Eine gute Datenbankwahl reflektiert, was das Produkt tut, wie es sich unter Last verhalten muss und was dein Team realistisch betreiben kann.
Fang mit der Form des Produkts an: die Kernentitäten, wie sie sich zueinander verhalten und welche Queries reale Workflows antreiben.
Brauchst du ad-hoc-Filterung und Reporting über viele Attribute? Verlass du dich auf Joins über Beziehungen? Liest du meist einzelne Datensätze per ID oder scannst du Zeitbereiche? Diese Details bestimmen, ob SQL-Tabellen, Dokumentmodelle, Wide-Column-Pattern oder Suchindizes am besten passen.
Datenbanken werden genauso sehr durch Einschränkungen wie durch Features gewählt:
Ein System, das ein paar Sekunden Verzögerung toleriert, unterscheidet sich stark von einem, das eine Zahlung in unter 200ms bestätigen muss.
Selbst ein „perfektes“ Datenmodell scheitert, wenn der Betrieb nicht passt:
Compliance-Anforderungen können die Auswahl schnell einschränken:
LLMs leiten diese Bedürfnisse bei vagen Prompts oft nur implizit ab—explizit zu sein ist der Unterschied zwischen einer hilfreichen Empfehlung und einem selbstbewussten Fehler.
LLMs ordnen wenige genannte Bedürfnisse („Echtzeit“, „skaliert“, „flexibles Schema“) bekannten Kategorien zu („NoSQL verwenden“, „Postgres verwenden“). Das kann beim Brainstorming nützlich sein, aber die Argumentation driftet ab, wenn das Modell Datenbank-Features so behandelt, als wären es Produktanforderungen.
Eine Feature-Liste (Transaktionen, JSON-Unterstützung, Volltextsuche, Sharding) klingt konkret, aber Produktanforderungen beschreiben meist Ergebnisse: akzeptable Latenz, Korrektheitsregeln, Prüfpfade, Teamfähigkeiten, Migrationsbeschränkungen und Budget.
Ein LLM kann Features abhaken und trotzdem übersehen, dass das Produkt vorhersehbare Support-Workflows, ein reifes Ökosystem oder eine Hosting-Option benötigt, die deinem Unternehmen erlaubt ist.
Viele Empfehlungen gehen davon aus, dass wenn eine Datenbank einen Datentyp speichern kann, sie das Produkt gut bedient. Das Schwierige ist die Beziehung zwischen Daten und Queries: wie du filterst, joinst, sortierst und aggregierst—bei welchem Volumen und mit welchen Update-Mustern.
Zwei Systeme, die beide „User Events“ speichern können, verhalten sich sehr unterschiedlich, je nachdem ob du brauchst:
LLMs sagen vielleicht „Datenbank X ist schnell“, aber Performance hängt von Schema-Entscheidungen, Indizes, Partitionierung, Query-Mustern und Konkurrenz ab. Kleine Änderungen—wie ein zusammengesetzter Index oder das Vermeiden ungebundener Scans—können das Ergebnis umdrehen. Ohne repräsentative Daten und Queries ist „schnell“ nur eine Vermutung.
Selbst wenn zwei Datenbanken technisch Anforderungen erfüllen können, ist oft die bessere Wahl diejenige, die dein Team zuverlässig betreiben kann: Backup- und Restore-Zeit, Monitoring, On-Call-Last, Vendor-Lock-in und Kostenplanbarkeit.
LLMs gewichten diese Realitäten oft zu gering, es sei denn, du gibst sie ausdrücklich an.
LLMs antworten oft mit weit verbreiteten „Regeln“, wie „NoSQL skaliert besser“ oder „Postgres kann alles“. Diese Vereinfachungen klingen selbstsicher, glätten aber die unordentliche Realität von Produkten: was du speicherst, wie du es abfragst und was bei Fehlern passiert.
Ein gängiges Muster ist die Annahme, wenn du Wachstum, hohen Traffic oder „Big Data“ erwähnst, sei NoSQL die sicherste Wahl. Das Problem: Skalierung ist selten das erste ungelöste Problem. Viele Apps stoßen an Limits wegen:
In solchen Fällen löst ein Wechsel der Datenbank nicht die Grundursache—er ändert nur die Werkzeuge.
Faustregeln glätten auch Anforderungen, die die Datenbankpassung stark beeinflussen. Ein LLM könnte einen Document-Store empfehlen und gleichzeitig übersehen, dass du brauchst:
Diese Bedürfnisse schließen NoSQL nicht automatisch aus, erhöhen aber den Aufwand: sorgfältiges Schemadesign, zusätzliche Applikationslogik oder andere Kompromisse als das LLM andeutete.
Wenn eine Empfehlung auf einem Slogan statt auf deinen tatsächlichen Access-Patterns basiert, ist das Risiko nicht nur eine suboptimale Wahl—es ist eine kostspielige Replattformung später. Migrationen, Query-Rewriting und Umschulungen treten oft genau dann ein, wenn man es sich am wenigsten leisten kann.
Behandle „Regeln“ als Aufforderung zu Fragen, nicht als Antworten. Frage, was genau du skalierst (Reads, Writes, Analytics), was korrekt sein muss und welche Queries unvermeidbar sind.
LLMs sind gut darin, eine kurze Beschreibung in eine selbstbewusste Datenbankwahl zu verwandeln—aber sie können die fehlenden Beschränkungen, die tatsächlich entscheiden, ob eine Wahl funktioniert, nicht erfinden. Sind die Eingaben vage, wird die Empfehlung zu einem als Antwort verpackten Raten.
Wörter wie „Echtzeit“, „hoher Traffic“, „skalierbar“ oder „enterprise-grade“ sind nicht eins-zu-eins auf eine konkrete Datenbank übertragbar. „Echtzeit“ kann „Updates innerhalb von 5 Sekunden“ für ein Dashboard oder „<50ms end-to-end" für Trading-Alerts bedeuten. "Hoher Traffic" kann 200 Requests/s oder 200.000 Requests/s meinen.
Ohne harte Zahlen greift ein LLM oft auf populäre Heuristiken zurück (z. B. „NoSQL für Scale“, „Postgres für alles“), selbst wenn die tatsächlichen Anforderungen anders liegen.
Wenn du diese nicht angibst, nimmt das Modell stillschweigend an:
Die schädlichsten Auslassungen sind oft Query-geformt:
Eine Datenbank, die bei Key-Value-Zugriff glänzt, kann Probleme haben, wenn das Produkt plötzlich flexible Filterung und verlässliches Reporting braucht.
Behandle „Datenbankauswahl“ als Zwei-Schritt-Interaktion: Zuerst Anforderungen sammeln, dann empfehlen. Ein guter Prompt (oder eine interne Checkliste) sollte Zahlen und Beispielqueries verlangen, bevor eine Engine genannt wird.
Ein häufiger LLM-Fehler ist, eine Datenbankkategorie (SQL, Document, Graph, Wide-Column) zu empfehlen, ohne zu prüfen, ob die Produktdaten tatsächlich zu diesem Modell passen. Ergebnis: ein Store, der sich richtig anhört, aber gegen die Struktur der abzubildenden Informationen arbeitet.
LLMs übergehen oft Tiefe und Kardinalität von Beziehungen: one-to-many vs many-to-many, verschachtelte Ownership, geteilte Entitäten und wie häufig Nutzer diese traversieren.
Eine Dokumentdatenbank wirkt vielleicht natürlich für „User Profiles“, aber wenn dein Produkt ständig Cross-Entity-Queries beantwortet—„alle Projekte, bei denen sich in den letzten 7 Tagen die Rolle eines Mitglieds geändert hat" oder „Top-20 Tags über alle Teams gefiltert nach Compliance-Status“—dann holst du nicht einfach ein Dokument, sondern musst Konzepte joinen.
Bei häufigen Joins wirst du entweder:
Duplikation ist nicht gratis. Sie erhöht Schreibamplifikation, macht Updates schwerer konsistent zu halten, verkompliziert Audits und kann subtile Bugs erzeugen („Welche Kopie ist die Wahrheit?“). LLMs empfehlen Denormalisierung manchmal, als wäre es eine einmalige Modellwahl statt einer fortlaufenden betrieblichen Belastung.
Bevor du eine LLM-Empfehlung akzeptierst, zwinge einen kurzen Realitätscheck:
Wenn Modell und Queries nicht übereinstimmen, ist die Empfehlung Lärm—auch wenn sie souverän klingt.
LLMs behandeln „Konsistenz“ oft wie eine Präferenz statt wie eine Produktanforderung. Das führt zu Empfehlungen, die auf dem Papier plausibel aussehen („verwende einen skalierbaren NoSQL-Store"), aber in der Praxis scheitern, wenn echte Nutzeraktionen atomare, mehrstufige Updates erfordern.
Viele Produktabläufe sind keine Einzel-Write-Operationen—sie bestehen aus mehreren Writes, die entweder alle passieren oder gar nicht.
Payments ist das klassische Beispiel: erst eine Belastung erstellen, dann eine Rechnung als bezahlt markieren, Kontostand reduzieren und einen Audit-Eintrag anfügen. Scheitert einer der Folgeschritte, nachdem der erste Erfolg hatte, entsteht eine Inkonsistenz, die Nutzer und Buchhaltung bemerken.
Ähnlich beim Inventar: reserviere Bestand, erstelle eine Bestellung und aktualisiere Verfügbarkeit. Ohne Transaktionen kannst du bei Spitzen verkaufen, die gar nicht verfügbar sind.
LLMs setzen eventual consistency bisweilen mit „die UI kann später aktualisieren" gleich. Entscheidend ist aber, ob die geschäftliche Aktion Divergenz toleriert.
Buchungskonflikte zeigen, warum das wichtig ist: Zwei Nutzer buchen denselben Slot. Wird beides akzeptiert und später „aufgelöst“, ist das keine bessere UX—es ist ein Support- und Refund-Problem.
Selbst mit einer Datenbank, die Transaktionen unterstützt, braucht der umgebende Workflow klare Semantik:
Wenn ein LLM diese Punkte ignoriert, empfiehlt es womöglich Architekturen, die erst Expert-Level verteilte Systeme-Arbeit benötigen, um normale Produktkorrektheit zu erreichen.
LLMs empfehlen oft eine „schnelle" Datenbank, als wäre Geschwindigkeit eine inhärente Eigenschaft der Engine. In Wahrheit ist Performance eine Interaktion zwischen Workload, Schema, Query-Form, Indizes, Hardware und Betriebsparametern.
Wenn du nicht spezifizierst, was schnell sein muss—p99 Latenz für Single-Row-Reads, Batch-Analytics, Ingest-Durchsatz oder Time-to-First-Byte—greift das LLM gern auf populäre Optionen zurück.
Zwei Produkte können beide „niedrige Latenz" sagen und trotzdem entgegengesetzte Zugriffsmuster haben: das eine Key-Value-Lookups, das andere Suche + Filter + Sort über viele Felder.
Performance-Ratschläge driften auch ab, wenn Modelle ignorieren:
Ein LLM nimmt vielleicht an, Caches würden helfen, aber Caches nützen nur bei vorhersehbaren Zugriffsmustern. Queries, die große Bereiche scannen, nach nicht-indizierten Feldern sortieren oder ad-hoc-Filter nutzen, treffen den Cache oft nicht und belasten Disk/CPU.
Kleine Änderungen in der Query-Form (z. B. OFFSET-Paginierung vs Keyset-Pagination) können Performance-Ergebnisse umdrehen.
Statt generischen „X ist schneller als Y“-Aussagen solltest du einen leichten, produktnahen Test laufen lassen:
Benchmarks sagen nicht alles voraus, aber sie zeigen schnell, ob die Performance-Annahmen eines LLMs zur Realität passen.
LLMs optimieren oft für Passung auf dem Papier—Datenmodell, Query-Muster, Skalierungs-Buzzwords—während sie übersehen, was eine Datenbank in Produktion überlebensfähig macht: Betrieb, Ausfallwiederherstellung und die echte Rechnung, die du monatlich bezahlst.
Eine Datenbankempfehlung ist nicht vollständig, wenn sie grundlegende Fragen nicht beantwortet: Wie machst du konsistente Backups? Wie schnell kannst du wiederherstellen? Was ist der Disaster-Recovery-Plan über Regionen hinweg?
LLM-Ratschläge überspringen diese Details oft oder gehen davon aus, dass sie „eingebaut" sind, ohne das Kleingedruckte zu prüfen.
Migration ist ein weiterer blinder Fleck. Ein späterer Wechsel ist teuer und risikoreich (Schema-Änderungen, Dual-Writes, Backfills, Query-Rewrites). Wenn dein Produkt sich wahrscheinlich weiterentwickelt, reicht „leicht zu starten" nicht—du brauchst einen realistischen Migrationspfad.
Teams brauchen nicht nur eine Datenbank—sie müssen sie betreiben.
Wenn die Empfehlung langsame Query-Logs, Metriken, Dashboards, Tracing-Hooks und Alerts ignoriert, bemerkst du Probleme erst, wenn Nutzer sich beschweren. Operative Tools unterscheiden sich stark zwischen Managed-Angeboten und Self-Hosted-Setups sowie zwischen Anbietern.
LLMs unterschätzen Kosten oft, weil sie sich auf Instanzgröße konzentrieren und Multiplikatoren vergessen:
Eine „beste" Datenbank, die dein Team nicht sicher betreiben kann, ist selten die beste Wahl. Empfehlungen sollten zu Teamfähigkeiten, Support-Erwartungen und Compliance-Anforderungen passen—sonst wird das Betriebsrisiko zum dominanten Kostenfaktor.
LLMs schlagen manchmal vor, „alles auf einmal zu lösen" mit einem Stack wie: Postgres für Transaktionen, Redis fürs Caching, Elasticsearch für Suche, Kafka + ClickHouse für Analytics plus eine Graphdatenbank „für den Fall“. Das klingt beeindruckend, ist aber oft ein verfrühter Entwurf, der früher mehr Arbeit schafft als Nutzen—gerade am Anfang eines Produkts.
Polyglotte Persistenz fühlt sich wie eine Absicherung an: Jedes Tool ist „das Beste" für eine Aufgabe. Der versteckte Preis ist, dass jeder zusätzliche Datastore Deployment, Monitoring, Backups, Migrationen, Zugriffskontrolle, Incident-Response und neue Fehlerarten mit sich bringt.
Teams verbringen dann Zeit mit Infrastruktur statt mit Produktfunktionen.
Eine zweite (oder dritte) Datenbank ist meist gerechtfertigt, wenn es eine klare, gemessene Anforderung gibt, die die primäre Datenbank nicht ohne unzumutbaren Aufwand erfüllt, z. B.:
Wenn du nicht die konkrete Query, das Latenzziel, die Kostenbedingung oder das operationelle Risiko benennen kannst, ist es wahrscheinlich verfrüht.
Sobald Daten an mehreren Orten leben, stehen harte Fragen an: Welcher Store ist die Quelle der Wahrheit? Wie hältst du Datensätze bei Retries, Teilausfällen und Backfills konsistent?
Duplizierte Daten bedeuten auch duplizierte Bugs—veraltete Suchergebnisse, inkonsistente Nutzerzahlen und „es kommt drauf an, welches Dashboard du ansiehst"-Meetings.
Beginne mit einer allgemeinen Datenbank, die deine Kern-Transaktionen und Reports abdeckt. Füge einen spezialisierten Store erst hinzu, wenn du (1) zeigen kannst, dass das aktuelle System gegen eine Anforderung versagt, und (2) ein Verantwortungsmodell für Sync, Konsistenz und Recovery definierst.
Behalte die Notausstieg-Option, nicht die Komplexität.
LLMs können bei der Erstellung eines Erstdrafts für eine Datenbankempfehlung helfen, aber behandle das Ergebnis als Hypothese. Nutze die folgende Checkliste, um die Vorschläge zu validieren (oder abzulehnen), bevor du Zeit in Engineering steckst.
Formuliere den Prompt als explizite Anforderungen. Wenn du das nicht klar hinschreiben kannst, hat das Modell vermutlich geraten.
Entwirf die echten Entitäten und Beziehungen (auch als Skizze). Dann listet die wichtigsten Zugriffsmuster.
Übersetze „schnell und zuverlässig" in messbare Tests.
Nutze realistische Datenformen und Query-Mischungen, nicht Spielzeugbeispiele. Lade einen repräsentativen Datensatz, führe Queries unter Last aus und messe.
Wenn das LLM mehrere Datenbanken vorgeschlagen hat, teste zuerst die einfachste Single-DB-Option und beweise dann, warum eine Aufteilung nötig ist.
Wenn du diesen Schritt beschleunigen willst, ist ein praktischer Ansatz, genau die Produktfunktion zu prototypisieren, die die Datenbankentscheidung antreibt (ein paar Kernentitäten + die Schlüssendpunkte + die wichtigsten Queries). Einige Plattformen wie Koder können hier helfen: Du beschreibst den Workflow im Chat, erzeugst eine lauffähige Web-/Backend-App (häufig React + Go + PostgreSQL) und iterierst schnell, während du Schema, Indizes und Query-Formen verfeinerst. Features wie Planungsmodus, Snapshots und Rollback sind besonders nützlich beim Experimentieren mit Datenmodellen und Migrationen.
Schreibe eine kurze Begründung: warum diese Datenbank zum Workload passt, welche Kompromisse du eingehst und welche Metriken eine erneute Bewertung erzwingen würden (z. B. andauerndes Write-Wachstum, neue Query-Typen, Multi-Region-Anforderungen, Kosten-Schwellen).
Behandle sie als eine Hypothese und als Möglichkeit, das Brainstorming zu beschleunigen. Nutze die Empfehlung, um Trade-offs, fehlende Anforderungen und eine erste Shortlist zu identifizieren – und validiere sie dann mit deinem Team, realen Restriktionen und einem schnellen Proof-of-Concept.
Weil deinem Prompt meist harte Randbedingungen fehlen. Das Modell wird oft:
Lass das Modell seine Annahmen explizit auflisten, bevor es eine Datenbank nennt.
Gib Zahlen und Beispiele, nicht nur Adjektive:
Kannst du das nicht angeben, ist die Empfehlung größtenteils geraten.
Nutze das LLM zur Erstellung einer Anforderungsliste und möglicher Optionen, dann prüfe Schema und Queries in der Realität:
„Skalierung“ ist kein Datenbanktyp, sondern das, was du skalierst.
Viele Apps stoßen auf Limits wegen:
Ein gut gestaltetes relationales System kann oft weit skalieren, bevor ein Wechsel der Datenbank nötig ist.
Sie sind in Empfehlungen oft unterschätzt.
Wenn dein Produkt mehrstufige Updates braucht, die zusammen erfolgreich sein müssen (Payments, Inventar, Buchungen), brauchst du klare Unterstützung für:
Wenn ein LLM nicht nach diesen Punkten fragt, hakt nach, bevor du seine Empfehlung übernimmst.
Weil Datenbeziehungen die Komplexität der Abfragen bestimmen.
Wenn du häufig Cross-Entity-Queries brauchst (Filter, Joins, Aggregationen über viele Attribute), zwingt ein Dokumentmodell dich häufig zu:
Das erhöht Schreibamplifikation, Inkonsistenzrisiko und betrieblichen Aufwand.
Performance hängt von deinem Workload, Schema, Indizes und Concurrency ab – nicht vom Markennamen.
Führe einen kleinen, produktnahen Test durch:
Weil jeder zusätzliche Datastore die Betriebsoberfläche vervielfacht:
Starte mit einer universellen Datenbank für den Kern-Workload. Füge eine zweite Lösung nur hinzu, wenn du eine gemessene Anforderung benennen kannst, die die erste nicht erfüllt.
Fordere ein Kostenmodell an, das die echten Multiplikatoren berücksichtigt:
Bestehe außerdem auf einem Betriebsplan: Backup-/Restore-Schritte, RPO/RTO-Ziele und wie langsame Queries oder Kapazitätsengpässe entdeckt werden.
