Jede Architekturprüfung für ein agentisches KI-Projekt endet mit derselben Frage: Kann der Stack, den wir bereits haben, das unterstützen, was wir entwickeln werden? Es ist verlockend, diese Frage durch ein Benchmarking von Vector Databases zu beantworten. Die grundlegendere Frage ist, ob Ihre Architektur Fragen zu Daten und der Bedeutung in derselben Abfrage mit denselben Garantien beantworten kann.

Das ist es, was ein Agent tatsächlich braucht. Es ist der Teil des Stacks, den die meisten Teams als letztes festlegen, nachdem der Rest des Systems bereits Gestalt angenommen hat. Die Betriebsdatenbank wird als gegeben behandelt. Laut Harvard Business Review Analytic Services halten nur 15 % der Unternehmen ihre Datengrundlage für agentenbasierte KI für geeignet. Das Ergebnis ist eine geteilte Architektur, die auf dem Whiteboard vernünftig aussieht, aber in der Produktion auseinanderfällt.

Die beiden Muster sind einen ehrlichen Vergleich wert:

• Vereinheitlichte Architektur: Eine einzige Plattform verarbeitet operative Daten und Vektorsuche gemeinsam.
• Geteilte Architektur: Ein dedizierter Vektorspeicher (Pinecone, Weaviate oder eine Such-Engine wie Elasticsearch) befindet sich neben der operativen Datenbank, wobei eine ETL-Pipeline die beiden synchronisiert.

Dekonstruktion des viralen Migrationszyklus von Postgres

Alle paar Monate verbreitet sich ein vertrauter Blogbeitrag in der Entwickler-Umgebung wie ein Lauffeuer: „Warum wir zurück zu Postgres gewechselt sind.“ Fast augenblicklich füllen sich die Kommentarstränge mit genau den gleichen vorhersehbaren Diskussionspunkten: MongoDB skaliert nicht, es gibt keine Joins und Transaktionen sind schwach. Tim Carter Clausen, der als The Decipherist schreibt und MongoDB seit einem Jahrzehnt in der Produktion betreibt, geht direkt auf jede Kritik ein, wobei er reale Produktionsdaten hinter sich hat.

Wenn Sie eine Datenbank wählen, deren Datenmodell zum restlichen Stack passt, wird sichergestellt, dass Ihre Engineering-Geschwindigkeit nicht durch architektonische Verzögerungen beeinträchtigt wird.

Tiefer Einblick: Die Kosten der SQL-Übersetzungssteuer

Eine typische SQL-Anfrage nimmt bei einem einzigen Schreibvorgang acht Formatänderungen vor:

1. Der Kunde schickt JSON.
2. Die API wandelt es in ein JavaScript-Objekt um.
3. Ein ORM-Tool zerlegt dieses Objekt in Zeilen, die über normalisierte Tabellen verteilt sind.
4. Die Datenbank macht ihre Arbeit.
5. Die Zeilen werden wieder zusammengesetzt.
6. Sie werden wieder einem Objekt zugeordnet.
7. Das Objekt wird wieder in JSON serialisiert.
8. Die Antwort wurde gesendet.

Das Äquivalent bei MongoDB besteht aus vier Transformationen, und Clausen argumentiert, dass die Bezeichnung „vier“ übertrieben ist, da sich die Form der Daten eigentlich nie ändert. Jede Formatänderung im SQL-Pfad verbraucht CPU und Speicher, führt zu Latenz und bietet einen Ort, an dem sich ein Fehler verbergen kann.

Die Realität von Schema-Aktualisierungen

Das Umbenennen eines Felds, das Hinzufügen eines verschachtelten Objekts oder die Umstrukturierung eines Dokuments erfolgen live in MongoDB ohne Ausfallzeiten. Derselbe Vorgang bei einer großen relationalen Tabelle kann Schreibzugriffe für Minuten oder sogar Stunden sperren. Für Teams, die wöchentlich liefern, ist der Unterschied nicht theoretischer Natur. Es ist der Unterschied zwischen dem Hinzufügen eines Feldes heute Nachmittag und der Planung eines Wartungsfensters im nächsten Quartal.

Die latente Steuer auf der Indexschicht

Die gleiche architektonische Divergenz zeigt sich auch, auf der Indexierungsebene. Betrachten Sie eine Abfrage, die jedem, der ein Betriebssystem betreibt, vertraut ist: Geben Sie die letzten 10 Bestellungen für ein bestimmtes Produkt in einem bestimmten Land zurück.

• Im Dokumentmodell: Ein einzelner zusammengesetzter Index dient direkt dazu, einschließlich der in Arrays verschachtelten Felder.
• In einem relationalen System (JSONB): Das Äquivalent erfordert typischerweise einen GIN-Index für die Array-Inhalte, einen separaten B-Baum-Index für die skalaren Felder und eine umfassende Sortierung, die der Abfrageplaner nicht vermeiden kann. Der Plan liest mehr Zeilen als notwendig, was bei wachsenden Daten eine ungünstige Skalierung bewirkt. Nichts davon ist von der Anwendungsebene aus sichtbar, aber alles davon ist auf Ihrer Cloud-Rechnung ersichtlich.

Die strukturelle Kraft der Datenlokalität

Der strukturelle Aspekt, der beiden Punkte zugrunde liegt, ist die Datenlokalität. Im Dokumentmodell sind das logische Modell und das physische Modell identisch. Die Form, die die Anwendung erzeugt, ist die exakte Form, die die Datenbank speichert, und die Form, die die Datenbank speichert, ist die exakte Form, die die Abfrageschicht an einen KI-Agenten zurückgibt. Diese Äquivalenz eliminiert vollständig die Synchronisationspipelines, die Double-Write-Logik und die komplexen Abstimmungsaufgaben, die fragmentierte Architekturen sonst benötigen, um dasselbe Ergebnis zu erzielen.

Entscheidungs-Framework für Architekten

Pachots Entscheidungs-Framework orientiert sich an diesen technischen Realitäten:

• Relationale Auswahl (Postgres): Für eine zentralisierte Datenbank, die viele unterschiedliche Anwendungen bedient, für die ultimativen Anwendungsfälle noch nicht alle bekannt sind.
• Dokumentauswahl (MongoDB): Für eine einzelne Anwendung, die auf einem Domänenmodell basiert und genau so persistiert wird, wie die Anwendung es begründet.

Die nächste Frage, die sich stellt, lautet: Was trifft am ehesten auf das Projekt zu, das Sie im Jahr 2026 entwickeln: Microservices mit abgegrenzten Kontexten, Schemata, die wöchentlich aktualisiert werden, oder Domänenobjekte, die so gespeichert werden, wie Ihre Anwendung sie ganz natürlich versteht?

„Eine Datenbank ist gut und schnell, wenn man sie richtig benutzt, und am wichtigsten ist es, eine auszuwählen, die man kennt oder die kennenlernen möchte.“
— Franck Pachot, AWS Data Hero & Oracle Certified Master

Zum Beitrag