Wir stellen vor: Lakebase Search – Agenten-natives Retrieval, integriert in Lakebase Postgres

Heute führen wir Lakebase Search ein: ein in Lakebase integriertes hybrides Vektor- und Volltext-Retrieval, das ab sofort als Beta-Version auf AWS und Azure verfügbar ist. Unterstützt durch zwei native Postgres-Erweiterungen, lakebase_vector und lakebase_text, ermöglicht es Ihrem gesamten Agenten-Loop, auf ein einziges Daten-Backend, eine Lakebase, zuzugreifen.

Dies sorgt für Skalierbarkeit auf neuem Niveau, erstklassige Wirtschaftlichkeit und eine auf Agenten ausgerichtete Ergonomie.

Agenten verwandeln die Suche in einen operativen Workflow: Sie rufen Kontext ab, schlussfolgern, agieren und erinnern sich. Dies verbindet den Lesepfad (Retrieval) eng mit dem Schreibpfad (Speicher), sodass ein sofortiges Retrieval unerlässlich ist, um in Echtzeit auf neu generierte Erkenntnisse zuzugreifen.

Bisher hatte dieser Loop kein Postgres-natives Zuhause, das für die Skalierbarkeit und Wirtschaftlichkeit ausgelegt war, die eine großflächige Suche erfordert.

Für Agenten ist die Suche eigentlich ein operativer Workload

Agenten betreiben mittlerweile viermal mehr Datenbanken auf Lakebase als menschliche Nutzer, und ihre Hauptanforderung unterscheidet sich grundlegend von der eines Menschen. Traditionelle Suchmaschinen gehen von einem schreibgeschützten Snapshot veralteter Daten aus. Agenten hingegen behandeln die Suche wie eine aktive, operative Datenbank.

Betrachten Sie ein typisches Agenten-Schema: In Chunks unterteilte Dokumente und Embeddings liegen direkt neben einem aktiven Konversations-Memory-Log. Dies führt zu einem kontinuierlichen Lese-/Schreib-Loop. Agenten schreiben in einem Schritt neue Erkenntnisse in den Speicher und müssen genau diese Daten im nächsten Schritt vollständig indexiert und durchsuchbar vorliegen haben. Sie benötigen nicht nur ein schnelles Retrieval, sondern eine sofortige Suche auf den absolut neuesten Schreibvorgängen.

Die Suche ist ein ungewöhnlicher Workload

Die Suche ist ein einzigartiger Workload mit zwei bestimmenden Eigenschaften.

Erstens speichern Sie weitaus mehr Daten, als Sie tatsächlich abfragen, sodass der Großteil davon ungenutzt bleibt („cold“).

Zweitens führt die Vektorsuche zu einem enormen Datenwachstum. Eine 1 KB große Textdatei vergrößert sich bei der Vektorisierung. Das liegt daran, dass das Dokument in mehrere Chunks aufgeteilt wird, wobei jeder Chunk ein eigenes hochdimensionales Embedding generiert – noch vor Berücksichtigung des Index-Overheads.

Wenn sich dies über Tausende von meist inaktiven Mandanten multipliziert, brechen traditionelle Sucharchitekturen zusammen. Branchenübliche Vektorindizes wie HNSW sind grundlegend speichergebunden. Da ein schnelles Durchlaufen des Graphen stark darauf angewiesen ist, dass der Index im RAM verbleibt, ist das Hosting inaktiver Multi-Tenant-Daten teuer.

Die Suche braucht eine Lakebase

Letztes Jahr haben wir Lakebase vorgestellt: eine serverlose Postgres-OLTP-Architektur, bei der Daten in kostengünstigem Cloud-Objektspeicher liegen, aber ein mehrstufiger Cache (RAM, lokales NVMe, Pageserver) dafür sorgt, dass aktive Seiten („hot pages“) mit der Latenz einer lokalen Festplatte gelesen werden.

Wir haben erkannt, dass dies genau die Architektur ist, die eine moderne Suche benötigt. Aber es gab einen Haken: Um diese Wirtschaftlichkeit tatsächlich ohne Einbußen bei der Abfragegeschwindigkeit zu nutzen, benötigt man ein Index-Layout, das explizit für eine mehrstufige Speicherhierarchie ausgelegt ist. Lakebase hatte keines. Also haben wir eines entwickelt.

Durch die Kombination einer mehrstufigen Architektur mit einem speziell entwickelten mehrstufigen Index erreichen wir:

• Skalierbarkeit auf neuem Niveau ohne Geschwindigkeitsverlust: Durch das intelligente Laden nur der benötigten Seiten aus dem Objektspeicher in einen lokalen Cache erzielen kleinere Postgres-Instanzen dieselbe Trefferquote (Recall) und Latenz, ohne massive Rechenressourcen zu benötigen.
• Wirtschaftlichkeit auf neuem Niveau: Der inaktive Teil („cold tail“) der Vektoren liegt im nahezu kostenlosen Objektspeicher, während der aktive Arbeitssatz („hot working set“) auf NVMe verbleibt. Sie zahlen für das, was Sie abfragen, nicht für das, was Sie speichern.

Die wirtschaftlichen Vorteile lassen sich am besten in einer Tabelle veranschaulichen. Pro Terabyte und Monat zu Cloud-Listenpreisen:

Dank unserer Indexierungsmethode muss Lakebase nur den aktiven Arbeitssatz im RAM halten. Der inaktive Großteil verbleibt im Objektspeicher, was das System um zwei Größenordnungen günstiger macht – bei gleichzeitig hoher Performance für die Suche, die Ihre Anwendung tatsächlich benötigt.

Lake-native Suchindizes für Postgres.

Bei der Entwicklung von Lakebase Search haben wir uns auf zwei unverzichtbare Eigenschaften konzentriert.

Bei der Entwicklung von Lakebase Search hatten wir zwei strenge Anforderungen: Es musste zu 100 % Postgres-nativ sein (unter Wiederverwendung von Standard-pgvector-/tsvector-Typen und Ökosystem-Tools) und die Indexierung musste von Grund auf für mehrstufigen Cloud-Objektspeicher konzipiert sein.

Um dies zu erreichen, veröffentlichen wir heute zwei neue Postgres-Erweiterungen in der Beta-Version. Beide verfolgen dasselbe Ziel: erstklassige Suchrelevanz zu bieten, ohne Sie zur Überdimensionierung des RAM zu zwingen.

1. lakebase_vector: 32-fache Komprimierung und Skalierung auf über 1 Mrd.

Wir haben die Standard-pgvector-Datentypen und -Operatoren beibehalten, aber den zugrunde liegenden Indextyp geändert. Da die Daten im nativen pgvector-Format verbleiben, bleibt die Kompatibilität gewahrt und sie können in andere Systeme exportiert werden. Durch das Clustern und Komprimieren von Vektoren mittels RaBitQ (Randomized Binary Quantization) reduzieren wir den Speicherbedarf des Index um das 32-Fache bei gleichbleibend hoher Trefferquote (Recall). Ein Index mit 100 Millionen Vektoren, der zuvor 300 GB RAM benötigte, passt nun in weniger als 10 GB. Dieser reduzierte Speicherbedarf ermöglicht es einem einzelnen Index, auf über 1 Milliarde Vektoren zu skalieren. Der aktive Arbeitssatz wird auf lokalem NVMe zwischengespeichert, während der inaktive Teil im Objektspeicher liegt.

2. lakebase_text: Echtes BM25 ohne den GIN-Speicher-Bloat.

Postgres verarbeitet exakte Keyword-Übereinstimmungen über GIN-Indizes, die im RAM verbleiben müssen, um die Performance aufrechtzuerhalten. Diese Architektur führt dazu, dass die Speicherkosten linear mit der Größe des Datensatzes skalieren.

lakebase_text ersetzt GIN durch einen Index, der für sequenzielle Lesevorgänge aus dem Cloud-Objektspeicher optimiert ist. Es führt ein natives BM25-Relevanz-Ranking in Postgres ein, ohne den damit verbundenen RAM-Bedarf.

Da beide Erweiterungen innerhalb derselben Engine ausgeführt werden, läuft die hybride Suche in einer einzigen SQL-Abfrage ab. Vektorähnlichkeit und Keyword-Relevanz werden über Reciprocal Rank Fusion (RRF) kombiniert, sodass Ergebnisse mit operativen Tabellen verknüpft und gefiltert werden können.

Postgres ist bereit für große, anspruchsvolle Such-Workloads

Wir haben Lakebase Search auf LAION-100M getestet – 100 Millionen 768-dimensionale Vektoren, Top-10-Retrieval auf einer einzelnen Instanz. Die Abfrage-Performance mit einem warmen Cache und einer einzelnen Verbindung liefert eine exakte Nearest-Neighbor-Trefferquote (Recall) ohne jeglichen Bloat:

Um diese Skalierung zu erreichen, ist traditionell eine speichergebundene Architektur erforderlich. Ein Standard-pgvector-HNSW-Index erfordert, dass der Nachbarschaftsgraph und seine Ziel-Heap-Seiten im RAM verbleiben, um ein performantes Durchlaufen zu ermöglichen. Bei 100 Millionen Vektoren:

1. pgvector: Erfordert eine Instanz mit 512 GB (64 CPU). Der Indexaufbau dauert ca. 40 Stunden. Da das Durchlaufen des Graphen auf nicht-lokalisiertem Zufallszugriff basiert, führen Kaltstarts zu hohen Festplatten-Leselatenzen, sodass die erste Abfrage Minuten dauert.
2. lakebase_vector: Läuft auf einer Instanz mit 192 GB (96 CU / 24 CPU). Der Indexaufbau dauert 1,5 Stunden. Obwohl das Durchlaufen weiterhin über Zufallszugriff erfolgt, clustert das Index-Layout die Daten so, dass zufällige Abfragen innerhalb eines aktiven Arbeitssatzes im NVMe-Cache lokalisiert werden, während der inaktive Teil im Objektspeicher verbleibt. Die Instanz skaliert bei Inaktivität auf Null; die erste Abfrage mit kaltem Cache dauert 1,13 Sekunden.

Diese Architektur verändert die Herangehensweise an die Gesamtbetriebskosten (TCO). Herkömmliche Suchen erfordern feste Basiskosten unabhängig vom Abfragevolumen, während Lakebase die tatsächliche Nutzung berücksichtigt:

Lakebase Search ermöglicht Agent-First-Ergonomie

Ein einziges Backend für Speicher und Kontext:

Agenten sollten nicht eine Vektordatenbank für den Kontext und eine transaktionale Datenbank für den Speicher zusammenflicken müssen. Indem Sie Ihre Retrieval-Logik direkt in die Datenbank verlagern, läuft Ihr gesamter Agenten-Loop auf einem einzigen Backend. Da Lakebase Search auf Postgres basiert – unter vollständiger Wiederverwendung der Standardtypen pgvector und tsvector –, lässt es sich nativ in Ihre bestehenden MCPs, Standardtreiber und Konnektoren integrieren. Und was noch wichtiger ist: Da sich die Suche direkt neben Ihren operativen Daten befindet, können Sie eine hybride Suche ausführen, Joins mit den Tabellen Ihrer Anwendung durchführen und sicher nach Mandanten filtern – und das alles in einer einzigen SQL-Abfrage.

Kontinuierliches Experimentieren mit der Suche

Die Optimierung von Chunking-Strategien oder hybriden Gewichtungen erfordert Ausprobieren. Anstatt Daten zur erneuten Verarbeitung in externe Batch-Systeme zu exportieren, verbindet sich Lakebase Search mit dem Lakehouse, um eine enge Feedbackschleife zu erstellen. Sie können Multi-Terabyte-Datensätze sofort und ohne Kosten verzweigen, Indizes separat über paralleles Compute erstellen und das Feedback der Agenten für die Offline-Evaluierung an das Lakehouse zurückleiten.

Eine dedizierte Retrieval-Engine pro Agent

Herkömmliche Architekturen erfordern die gemeinsame Nutzung eines einzigen Suchclusters durch alle Agenten. Da inaktive Indizes in Lakebase nahezu keine Speicherkosten verursachen, können Sie Tausende von isolierten Korpora bereitstellen, die für bestimmte Agenten, Benutzer oder Sitzungen dediziert sind. Dies verwandelt die Suche von einem veralteten Snapshot in einen operativen Lese-/Schreib-Loop; Daten, die ein Agent in einem Schritt schreibt, sind im nächsten Schritt mit vollen transaktionalen Garantien gespeichert und abrufbar.

Ein einziges Fundament für den Agenten-Loop

Lakebase macht das Zusammenflicken von separaten Vektorspeichern, Suchclustern und transaktionalen Datenbanken überflüssig. Durch die Konsolidierung des gesamten Lebenszyklus in einem einzigen Postgres-System bietet es die Skalierbarkeit und die geringen Kosten von mehrstufigem Cloud-Objektspeicher zusammen mit der für agentenbasierte Workflows erforderlichen Echtzeit-Lese-/Schreib-Ergonomie.

Lakebase Search ist ab heute als Beta-Version auf AWS und Azure verfügbar. Was werden Ihre Agenten entwickeln?

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag