Wie LLMs Datenbanken aus Produktanforderungen auswählen — und scheitern

Warum Teams LLMs nutzen, um Datenbanken auszuwählen

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.

Was „aus Produktanforderungen ableiten" wirklich bedeutet

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:

• relationale Daten → SQL
• flexible Dokumente → Document-Store
• Analytics → spaltenorientiertes Warehouse
• Caching → Key-Value-Store
• Volltextsuche → Suchmaschine

Diese Zuordnung kann früh sehr nützlich sein, besonders wenn die Alternative ein leeres Blatt ist.

Beratung vs. finale Architekturentscheidung

Eine LLM-Empfehlung sollte als Hypothese und nicht als Architektururteil behandelt werden. Sie kann dir helfen:

• die zentralen Fragen zu benennen, die beantwortet werden müssen
• offensichtliche Fehlanpassungen früh zu erkennen
• einen Decision-Memo zu entwerfen, das du im Team verfeinerst

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.

Was schiefgehen kann (und wie du das Risiko senkst)

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.

Wie LLMs Anforderungen in eine Datenbankauswahl übersetzen

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.

Was das Modell als Eingaben betrachtet

Die Eingaben sind nicht nur die expliziten Details, die du lieferst (Traffic, Datengröße, Konsistenzbedarf). Das Modell nutzt außerdem:

• die Wortwahl und Struktur deines Prompts (was du betonst, was du weglässt)
• deine Produktbeschreibung (es mappt „Chat“, „Analytics“, „Payments“, „IoT“ usw. auf typische Architekturen)
• angegebene Beschränkungen (Cloud-Provider, Budget, Teamfähigkeiten, Deadlines)
• gelernte „Vergangenheitsmuster“ aus Trainingsdaten (gängige Stacks, populäre Blog-Ratschläge, häufige Kombinationen)

Weil viele Prompts unvollständig sind, füllt das Modell Lücken oft mit impliziten Annahmen—manchmal richtig, manchmal nicht.

Was es als Ausgabe erzeugt

Die meisten Antworten landen auf drei Ebenen:

1. eine Kategoriewahl (SQL vs NoSQL; relational vs Dokument vs Key-Value)
2. konkrete Engines (PostgreSQL, MySQL, DynamoDB, MongoDB, BigQuery, Redis)
3. ein Paket von „Best Practices“ (Indizes, Caching, Read Replicas, Sharding, Event Sourcing)

Das Ergebnis kann sich wie eine klare Empfehlung anfühlen, ist aber oft eine strukturierte Zusammenfassung konventioneller Optionen.

Warum es sicher klingen kann, ohne sicher zu sein

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.

Was „Produktanforderungen" tatsächlich umfasst

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.

Funktionale Bedürfnisse (was du baust)

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.

Nicht-funktionale Bedürfnisse (wie es sich verhalten muss)

Datenbanken werden genauso sehr durch Einschränkungen wie durch Features gewählt:

• Latenzziele (p95/p99) für kritische Nutzeraktionen
• Verfügbarkeits- und Wiederherstellungsanforderungen (welche Downtime ist akzeptabel?)
• Read/Write-Mix und Traffic-Spitzen
• Wachstumsrate von Datenvolumen und Traffic über 6–24 Monate

Ein System, das ein paar Sekunden Verzögerung toleriert, unterscheidet sich stark von einem, das eine Zahlung in unter 200ms bestätigen muss.

Operative Bedürfnisse (was du betreiben kannst)

Selbst ein „perfektes“ Datenmodell scheitert, wenn der Betrieb nicht passt:

• Backups und Restore-Tests
• Migrationen und Schema-Evolution
• On-Call-Belastung und Personal (DBA-Erfahrung vs Generalisten)
• Anbieter-Limits: Managed-Service-Quotas, Region-Support, Wartungsfenster

Regulatorische Bedürfnisse (was du nachweisen musst)

Compliance-Anforderungen können die Auswahl schnell einschränken:

• Datenaufbewahrung und Löschgarantien
• Audit-Trails (wer hat wann was geändert)
• Zugriffskontrolle, Verschlüsselung und Trennung von Aufgaben

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.

Wo die LLM-Propädeutik von der Realität abweichen kann

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.

Features ≠ 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.

Checklisten übersehen die Form deiner Daten und Queries

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:

• ad-hoc-Analytics über viele Dimensionen
• per-User-Timelines mit strikter Reihenfolge
• Cross-Entity-Constraints (z. B. Inventar darf nicht unter 0 fallen)

Performance ist eine Implementierungsfrage, kein Versprechen

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.

Operative Passung kann Rohfähigkeiten überwiegen

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.

Fehlermodus 1: Überverallgemeinerung durch populäre Faustregeln

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.

Die klassische Abkürzung: „NoSQL für Scale"

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:

• fehlender Indizes oder ineffizienter Abfragen
• unbeschränkter Datenaufbewahrung
• schlechter Caching-Strategie
• mangelnder Ressourcenbereitstellung

In solchen Fällen löst ein Wechsel der Datenbank nicht die Grundursache—er ändert nur die Werkzeuge.

Was ignoriert wird: Joins, Transaktionen und strikte Korrektheit

Faustregeln glätten auch Anforderungen, die die Datenbankpassung stark beeinflussen. Ein LLM könnte einen Document-Store empfehlen und gleichzeitig übersehen, dass du brauchst:

• mehrstufige Updates, die zusammen Erfolg oder Fehlschlag benötigen (Transaktionen)
• strikte Korrektheit für Salden, Inventar oder Buchungen (starke Konsistenz)
• Reporting-Queries, die Daten über Entitäten hinweg verknüpfen (komplexe Joins)

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.

Warum dieser Fehler teuer ist

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.

Fehlermodus 2: Fehlende oder mehrdeutige Eingaben

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.

Die Falle „Echtzeit" und „hoher Traffic"

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.

Fehlende Zahlen, die die Antwort ändern

Wenn du diese nicht angibst, nimmt das Modell stillschweigend an:

• Read/Write QPS (Spitzen vs Durchschnitt)
• p95/p99 Latenzziele (und ob sie für Reads, Writes oder beides gelten)
• Datensatzgröße jetzt, Wachstumsrate, Retention-Policy
• Objektgröße (weite Rows? große Blobs?) und Index-Kardinalität

Versteckte Query-Muster, die du vergessen hast

Die schädlichsten Auslassungen sind oft Query-geformt:

• Reporting und Analytics (Group-Bys, Time Buckets)
• Filtern/Sortieren über viele Felder
• Ad-hoc-Abfragen für Support und Debugging
• Backfills, Reprocessing und „zeige mir alles für Nutzer X" Lookups

Eine Datenbank, die bei Key-Value-Zugriff glänzt, kann Probleme haben, wenn das Produkt plötzlich flexible Filterung und verlässliches Reporting braucht.

Praktischer Tipp: Klärung erzwingen, bevor du empfiehlst

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.

Fehlermodus 3: Datenmodell-Mismatch

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.

Das Mismatch beginnt meist bei Beziehungen

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:

• Joins in der Anwendung simulieren (zusätzliche Roundtrips und Komplexität), oder
• stark denormalisieren (Daten in Dokumenten duplizieren)

Die versteckten Kosten der Denormalisierung

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.

Sanity-Check: Kandidatenschema + Schlüsselqueries

Bevor du eine LLM-Empfehlung akzeptierst, zwinge einen kurzen Realitätscheck:

1. Skizziere ein Kandidatenschema (Tabellen/Sammlungen/Knoten) mit Primärschlüsseln und den wenigen kritischen Beziehungen.
2. Schreibe 5–10 „Keys Queries“, die das Produkt unterstützen muss (Filter, Sorts, Aggregationen, Cross-Entity-Lookups).
3. Frage: Drückt diese Datenbank diese Queries natürlich und effizient aus, ohne heldenhafte Denormalisierung oder mehrstufige App-Joins?

Wenn Modell und Queries nicht übereinstimmen, ist die Empfehlung Lärm—auch wenn sie souverän klingt.

Fehlermodus 4: Transaktionen- und Konsistenzblindheit

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.

Die Atomicity-Lücke: Mehrstufige Updates, die zusammen erfolgreich sein müssen

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.

Eventual Consistency ist nicht gleich „die Nutzer stören sich nicht"

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.

Fehlende operationale Semantik: Idempotenz, Retries, Exactly-Once

Selbst mit einer Datenbank, die Transaktionen unterstützt, braucht der umgebende Workflow klare Semantik:

• Idempotency Keys, damit ein doppelter „Bezahlt“-Klick nicht doppelt belastet.
• Retries, die bei Teilausfällen und Timeouts sicher sind.
• Exactly-once Effekte (oder eine bewusste Alternative wie „at-least-once + Dedupe") für Events, Webhooks und Hintergrundjobs.

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.

Fehlermodus 5: Performance-Annahmen ohne Tests

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.

„Schnell" ohne Workload-Kontext

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.

Versteckte Einschränkungen: Indizes, Amplifikation, Hot-Partitions

Performance-Ratschläge driften auch ab, wenn Modelle ignorieren:

• Index-Beschränkungen und Trade-offs: Sekundärindizes beschleunigen Reads, erhöhen aber Write-Kosten und Storage. Manche Systeme haben Einschränkungen bei zusammengesetzten Indizes, Index-Bauzeiten oder Online-Index-Änderungen.
• Write-Amplifikation: LSM-basierte Engines verwandeln „einfache Writes" in nennenswerte Hintergrundkompaktierungen, was bei dauerhaftem Ingest relevant ist.
• Hot-Partitions: Ein geshardetes Design kann trotzdem bottlenecken, wenn Traffic auf einem engen Key-Bereich konzentriert ist (z. B. neuster Tenant, heutiges Datum, ein populärer Artikel).

Cache-Verhalten und Query-Form

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.

Ein kleiner Benchmark-Plan (besser als Raten)

Statt generischen „X ist schneller als Y“-Aussagen solltest du einen leichten, produktnahen Test laufen lassen:

1. Wähle 3–5 repräsentative Queries (inkl. Worst-Case-Filtern und Sorts) und 1–2 Schreibmuster (steady + burst).
2. Nutze realistische Datenvolumina (mindestens groß genug, um den Speicher zu überschreiten; mit Skew und Hot-Keys).
3. Miss p50/p95/p99 Latenzen und Durchsatz separat für Reads und Writes.
4. Teste Index-Varianten (kein Index, minimale Indizes, „ideale“ Indizes) und notiere Schreib-Overhead.
5. Laufe mit Konkurrenz nahe an erwarteter Spitze und beobachte CPU, Disk, Kompaktierung und Lock-/Transaktionsmetriken.

Benchmarks sagen nicht alles voraus, aber sie zeigen schnell, ob die Performance-Annahmen eines LLMs zur Realität passen.

Fehlermodus 6: Operative und Kosten-Übersehen

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.

Die versteckte Arbeit: Backups, Recovery und Migration

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.

Observability ist Teil des Produkts

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.

Gesamtkosten sind mehr als der Stundenpreis

LLMs unterschätzen Kosten oft, weil sie sich auf Instanzgröße konzentrieren und Multiplikatoren vergessen:

• Speicherwachstum und Retention
• IOPS/Throughput-Preise und Burst-Limits
• Replikate für Read-Scale und Hochverfügbarkeit
• On-Call-Zeit, Incident-Response und Supportpläne

Passe die DB ans Team an

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.

Fehlermodus 7: Überkomplexe Multi-Datenbank-Designs

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.

Warum der Rat falsch geht

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.

Wann Polyglot gerechtfertigt ist

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.:

• Suchqualität/-latenz, die die Haupt-DB übersteigt
• Analytics-Workloads, die transaktionale Performance signifikant verschlechtern
• Skalierungsmuster, die unterschiedliche Speicher- oder Indexmodelle erfordern

Wenn du nicht die konkrete Query, das Latenzziel, die Kostenbedingung oder das operationelle Risiko benennen kannst, ist es wahrscheinlich verfrüht.

Cross-Store Konsistenz- und Duplikationsfallen

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.

Eine praktische Entscheidungsregel

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.

Eine praktische Validierungs-Checkliste für LLM-Datenbankempfehlungen

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.

1) Eingaben klären (aufschreiben)

Formuliere den Prompt als explizite Anforderungen. Wenn du das nicht klar hinschreiben kannst, hat das Modell vermutlich geraten.

• Was ist der Kern-Workload des Produkts: OLTP, Analytics, Search, Time Series, Messaging?
• Erwartete Skalierung: Nutzer, Writes/sec, Reads/sec, Speicherwachstum, Peak-to-Average-Verhältnis.
• Nicht-funktionale Bedürfnisse: Uptime, Multi-Region, Compliance, Budget, Teamfähigkeiten.

2) Modelliere die Daten und die Schlüsselqueries

Entwirf die echten Entitäten und Beziehungen (auch als Skizze). Dann listet die wichtigsten Zugriffsmuster.

• Was sind die Top-10 Reads und Writes?
• Welche Queries müssen bei Peak schnell sein?
• Was muss indiziert, gejoint, aggregiert oder durchsucht werden?

3) Definiere Akzeptanztests (Erfolgskriterien)

Übersetze „schnell und zuverlässig" in messbare Tests.

• Latenz- und Durchsatz-Ziele (p95/p99) für die Top-Queries
• Konsistenz- und Transaktionsanforderungen (was muss atomar sein?)
• Fehlerszenarien: Node-Ausfall, Netzwerkpartition, Regional-Failover, Backup/Restore-Zeit

4) Führe ein leichtgewichtiges Proof-of-Concept durch

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.

5) Dokumentiere die Entscheidung — und die „Change Triggers"

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).