Die meisten KI-Projekte scheitern nicht am Modell. Sie scheitern an der Infrastruktur drumherum, die niemand betreiben wollte und am Ende doch jemand betreiben muss.
Wenn ein Team heute "wir bauen RAG" sagt, landet auf dem Architektur-Whiteboard fast reflexartig eine zweite Datenbank: eine dedizierte Vektordatenbank neben der bestehenden PostgreSQL. Pinecone, Weaviate, Qdrant – die Namen wechseln, das Muster bleibt. Mit der zweiten Datenbank kommt die zweite Backup-Strategie, das zweite Monitoring, die zweite Zugriffskontrolle und der Sync-Job, der die Daten zwischen Primär-DB und Vektor-Store konsistent halten soll. Genau dieser Sync ist die Stelle, an der später um drei Uhr nachts das Pager-Duty-Telefon klingelt.
Warum Supabase als KI-Backend eine Konsolidierungsentscheidung ist
Supabase ist im Kern verwaltetes PostgreSQL mit Auth, Storage, Realtime und Edge Functions obendrauf. Wer noch nicht im Detail weiß, was das bedeutet, findet die Einordnung in unserem Grundlagenartikel zu Supabase. Der für KI entscheidende Baustein ist eine PostgreSQL-Extension namens pgvector. Sie fügt einen nativen Datentyp für Vektoren hinzu und macht Ähnlichkeitssuche zu einer SQL-Operation. Damit wird die Vektordatenbank PostgreSQL nicht zu einem Marketing-Slogan, sondern zu einer schlichten Tatsache: Der Vektor-Index lebt in derselben Datenbank wie Ihre Geschäftsdaten.
Das verschiebt die Frage. Sie lautet nicht mehr "welche Vektordatenbank kaufen wir", sondern "müssen wir überhaupt eine kaufen". Für ein Unternehmen, das KI-Features ins eigene Produkt integrieren will – semantische Suche über die Wissensdatenbank, ein Support-Assistent auf den eigenen Dokumenten, Produktempfehlungen über Embeddings – ist die Antwort in den meisten Fällen: nein.
Der Praxisanker ist banal und genau deshalb stark. Eine RAG Anwendung auf bereits vorhandenem PostgreSQL aufzusetzen heißt: keine zweite Datenbank einführen, betreiben, sichern und synchronisieren. Weniger bewegliche Teile bedeuten weniger Betriebsrisiko. Das ist kein KI-Argument. Das ist ein Operations-Argument, und Operations-Argumente sind die, die vor dem CFO standhalten.
Wie pgvector RAG und semantische Suche überhaupt löst
Ein Embedding ist ein Vektor – eine Liste von Zahlen, die die Bedeutung eines Textes, Bildes oder Produkts im Raum verortet. Inhalte, die sich ähneln, liegen nah beieinander. Semantische Suche ist dann nichts anderes als: Finde die Vektoren, die dem Such-Vektor am nächsten sind. pgvector liefert dafür die Distanz-Operatoren direkt in SQL – Cosine-Distanz mit <=>, L2 mit <->, das negative innere Produkt mit <#>, das in der Praxis am schnellsten ist.
Der entscheidende Punkt für die Architektur: Diese Suche läuft als Teil einer normalen SQL-Abfrage. Sie können Vektorähnlichkeit mit klassischen WHERE-Bedingungen kombinieren – nur Dokumente dieses Mandanten, nur Artikel aus diesem Zeitraum, nur Datensätze, die der angemeldete Nutzer sehen darf. In einer separaten Vektordatenbank pflegen Sie diese Metadaten-Filter parallel und hoffen, dass beide Systeme dieselbe Wahrheit erzählen.
In Supabase kapselt man das RAG-Retrieval üblicherweise in einer PostgreSQL-Funktion mit match_threshold und match_count, weil die darüberliegende API-Schicht Vektordistanzen nicht direkt ausdrücken kann. Das ist in der Supabase-Dokumentation zu Vector Columns sauber beschrieben. Der Nebeneffekt wiegt schwerer als die Einschränkung: Die Zugriffskontrolle über Row Level Security greift automatisch – auch auf die Suchergebnisse. Wer verstehen will, warum RLS hier so viel Last von den Schultern nimmt, findet die Begründung in unserem Artikel dazu, warum Supabase RLS ein Game Changer ist. Eine Vektordatenbank ohne zeilengenaue Berechtigungslogik zwingt Sie, genau diese Sicherheit in der Anwendungsschicht nachzubauen. Das ist die Art von Eigenbau, die in einem Pentest auffällt.
Für die Index-Wahl gibt pgvector zwei Optionen. HNSW baut einen mehrschichtigen Graphen, lässt sich auf einer leeren Tabelle anlegen und liefert den besseren Trade-off zwischen Geschwindigkeit und Recall. IVFFlat ist schneller gebaut und sparsamer im Speicher, muss aber nach dem Befüllen erstellt werden, weil er Zentroide trainiert, und bleibt im Speed-Recall-Vergleich schwächer. Für die meisten produktiven Setups ist HNSW die Wahl. Supabase hat das in einem eigenen Benchmark gegen IVFFlat gemessen: HNSW lag bei hoher Genauigkeit um mehr als das Sechsfache vorn, und bei sehr hohem Recall übertraf pgvectors HNSW auf gleicher Compute sogar eine dedizierte Vektordatenbank wie Qdrant. Die absoluten Throughput-Zahlen aus den Sekundärzusammenfassungen sind nur als grobe Indikation zu lesen – der relevante Befund sind die relativen Multiplikatoren, und die sind deutlich.
Was Edge Functions an den Stack bringen
Embeddings müssen irgendwo erzeugt werden, und der API-Schlüssel für das Embedding-Modell hat im Browser-Frontend nichts zu suchen. Hier kommen Supabase Edge Functions ins Spiel: serverlose Funktionen auf Deno-Basis, die direkt neben der Datenbank laufen. Der typische KI-Pfad sieht so aus: Ein neuer Datensatz wird eingefügt, ein Trigger reiht ihn in eine Queue, ein Scheduler ruft im Batch eine Edge Function, die das Embedding beim Modell anfragt und als Vektor zurückschreibt. Supabase hat dieses Muster unter dem Namen Automatic Embeddings mit vier Extensions standardisiert – pgvector für die Speicherung, pgmq für die Queue, pg_net für asynchrones HTTP, pg_cron für das Scheduling. Das ist kein Bastelwerk, sondern ein dokumentierter Pfad.
Wichtig ist, Edge Functions nicht zu überschätzen. Sie sind für kurzlebige Aufgaben gebaut, und die offiziellen Limits sagen das deutlich: 256 MB RAM, 2 Sekunden CPU-Zeit pro Request (reine asynchrone I/O zählt nicht mit), maximal 150 bis 400 Sekunden Wall-Clock je nach Plan, 20 MB Bundle-Größe. Webhooks, Embedding-Erzeugung, ein API-Proxy vor OpenAI oder einem self-hosted Modell – dafür sind sie ideal. Ein langlaufender Re-Indexing-Job über mehrere Millionen Dokumente gehört nicht in eine Edge Function, sondern in einen separaten Worker. Wer diese Grenze respektiert, bekommt ein sauberes Werkzeug. Wer sie ignoriert, baut sich Timeouts ein, die er später nicht versteht.
Die Gegenposition: Wann eine dedizierte Vektordatenbank die bessere Wahl ist
Ich tue nicht so, als gäbe es keine Fälle für Pinecone, Weaviate oder Qdrant. Es gibt sie. Bei zig Millionen Vektoren und hoher, anhaltender Query-Last skalieren spezialisierte Systeme besser, bieten feinere Tuning-Knöpfe, horizontale Sharding-Modelle und Betriebsmodi, die eine generische Datenbank nicht von Haus aus mitbringt. Wer eine öffentliche Suchmaschine über hunderte Millionen Embeddings betreibt, baut nicht auf pgvector. Das wäre das falsche Werkzeug, und ich würde es niemandem empfehlen.
Die ehrliche Faustregel aus Vergleichsanalysen – ausdrücklich eine Daumenregel, keine vom Anbieter garantierte Schwelle: Unterhalb von grob fünf bis zehn Millionen Vektoren bei moderater Query-Last ist pgvector der pragmatische Default, wenn ohnehin PostgreSQL im Stack liegt. ACID-Transaktionen, ko-lokalisierte Daten, eine Komponente weniger, die günstigste Option. Darüber, unter ernsthafter Last, gehört der Blick auf eine dedizierte Vektordatenbank ins Lastenheft.
Der Punkt ist die Verteilung der Realität. Die allermeisten Unternehmens-Use-Cases – die interne Wissenssuche über zehntausende Confluence-Seiten, der Produktkatalog mit einigen hunderttausend Artikeln, der Support-Bot auf der Dokumentation – liegen um Größenordnungen unter dieser Schwelle. Für sie ist eine dedizierte Vektordatenbank kein Vorteil, sondern überdimensionierte Infrastruktur, die jemand betreiben, bezahlen und gegenüber dem Vendor verantworten muss. Man kauft sich Komplexität für ein Skalierungsproblem, das man nie haben wird.
Der unbequeme Punkt: pgvector hat reale, physikalische Grenzen
Jetzt die Stelle, an der ich meine eigene These ehrlich kompliziere. pgvector ist gut, aber es ist kein Zaubertrick, und die Grenzen sind real.
Die zentrale Limitierung ist physikalisch: Der HNSW-Index muss in den Arbeitsspeicher passen. Solange er das tut, liefert pgvector beeindruckende Werte. Sobald der Index größer wird als die shared_buffers, bricht die Query-Performance nichtlinear ein – und zwar brutal. Im dokumentierten Performance-Issue #700 des pgvector-Projekts sind die Zahlen nachzulesen: Auf einer Maschine mit 16 GB shared_buffers lieferte der Index bei 2 Millionen Vektoren rund 2.110 Queries pro Sekunde. Bei 3 Millionen waren es noch 102. Bei 5 Millionen knapp 13. Das ist kein sanftes Abflachen, das ist eine Klippe.
Dasselbe gilt für den Index-Build. HNSW baut nur schnell, solange der Graph in maintenance_work_mem passt – der PostgreSQL-Default von 64 MB ist für ernsthafte Builds zu klein. Wird er überschritten, fällt der Build auf einen Disk-Spill-Pfad zurück, der laut Sekundärquellen zehn- bis fünfzigmal langsamer ist. Bei sehr großen Vektormengen wird der Index-Build damit zu einem echten Kostenfaktor, und HNSW zwingt zusätzlich zum Tuning zwischen Recall und Latenz über Parameter wie ef_search.
Die Konsequenz ist klar, nicht "es kommt darauf an": Wer von Tag 1 hunderte Millionen Vektoren mit garantierter Sub-10-Millisekunden-Latenz braucht, soll nicht so tun, als sei Postgres die Antwort. Für den ist die richtige Architektur eine dedizierte Vektordatenbank, Punkt. Aber dieses Anforderungsprofil ist die Ausnahme, und es ist intellektuell unredlich, eine pragmatische Default-Entscheidung mit einem Extremfall zu erschlagen, den man wahrscheinlich nie erreicht. Die richtige Frage an das eigene Projekt ist nicht "was wäre, wenn wir Google würden", sondern "wie viele Vektoren haben wir realistisch in drei Jahren". Diese Zahl kennt das Team meistens. Sie liegt fast immer im grünen Bereich.
Die Datenschutz-Dimension, die niemand wegmoderieren kann
Ein KI-Backend verarbeitet oft genau die Daten, die regulatorisch heikel sind – Kundendokumente, interne Wissensbestände, Support-Verläufe. Supabase erlaubt die Wahl einer EU-Region pro Projekt, etwa Frankfurt, und der gesamte Stack ist via Docker self-hostbar. Das ist die gute Nachricht für die Datensouveränität.
Die unbequeme Nuance bleibt: Supabase Inc. ist ein US-inkorporiertes Unternehmen und kann damit potenziell dem CLOUD Act unterliegen, auch bei EU-Speicherort. Das ist eine juristische Einordnung, keine Infrastruktur-Limitierung – aber für regulierte Branchen ein Punkt fürs Risk Management. Wer maximale Kontrolle braucht, betreibt den Stack self-hosted auf eigener EU-Infrastruktur, wo der CLOUD-Act-Angriffsvektor schlicht entfällt. Die rechtliche Tiefe dazu liefert unser Praxisleitfaden zu DSGVO-konformer KI auf der Website. Bei der Embedding-Erzeugung selbst gilt dieselbe Sorgfalt: Welches Modell die Daten sieht und wo es läuft, ist Teil derselben Souveränitätsfrage – nicht jedes Embedding muss zwingend bei einem US-Hyperscaler erzeugt werden.
Was ich Entscheidern rate
Behandeln Sie die Wahl des KI-Backends nicht als KI-Frage, sondern als das, was sie ist: eine Operating-Model-Entscheidung. Jede zusätzliche Komponente im Stack ist ein Vertrag, ein Betriebsaufwand, eine Schnittstelle, die brechen kann. pgvector in einem ohnehin vorhandenen PostgreSQL ist für die überwiegende Mehrheit der Unternehmens-Use-Cases die Architektur mit den wenigsten beweglichen Teilen – und damit dem niedrigsten Betriebsrisiko und der planbarsten TCO. Wer wissen will, wie sich diese Logik über drei Jahre rechnet, findet die Zahlen in unserer TCO-Betrachtung von Supabase in Produktion, und die strategische Gesamteinordnung von Supabase als europäische Backend-Plattform steht auf unserer Supabase-Übersichtsseite.
Die Konsolidierung ist der Gewinn, nicht das KI-Feature. Das Feature kann jeder bauen. Eine Komponente weniger zu betreiben, ist der Unterschied zwischen einem System, das Ihr Team beherrscht, und einem, das Ihr Team nur noch verwaltet. Fragen Sie nicht zuerst, welche Vektordatenbank die beste ist. Fragen Sie, ob Sie überhaupt eine zweite brauchen. Bei den meisten Projekten ist die ehrliche Antwort: nein – noch nicht, und vielleicht nie.
