Die Vektorsuche von Notion ist ausgezeichnet. Ihr nächstes Problem ist schwieriger.
Lektüre von "Two Years of Vector Search at Notion" — und was es darüber vorhersagt, was als Nächstes kommt
Notion veröffentlichte einen Engineering-Beitrag über zwei Jahre Infrastruktur für Vektorsuche. Ich habe ihn mit echter Bewunderung und einem starken Gefühl von Déjà-vu gelesen. Fast jedes Problem, das sie beschreiben, jede Migration, die sie durchgeführt haben, und jeder Workaround, den sie gebaut haben, hat eine enge Parallele in der Geschichte von Big Data. Big Data brauchte ungefähr fünfzehn Jahre, um sich auf seine langfristige Architektur zuzubewegen.
Was mich am meisten beeindruckte, war nicht nur die Qualität der Umsetzung. Es war, wie viel Aufwand in plattformbezogene Anliegen floss, die in einer vollständigeren Architektur eher in der Infrastruktur als im Product Engineering liegen sollten.
Wenn ich den Titel ihres nächsten Engineering-Beitrags erraten müsste, könnte er "Wie wir sechs Monate mit einem Upgrade des Embedding-Modells verbrachten." lauten. Oder "Wie wir hundert Millionen Workspaces ohne Ausfallzeit in einen neuen Vektorraum migrierten." Oder "Wie wir Offline Context Engineering bauten, um Notion AI ein dauerhaftes Gedächtnis zu geben."
Alles, was bisher gelöst wurde, ist Kapitel 1. Kapitel 2 ist schwieriger.
Was Notion gebaut hat
Die Geschichte beginnt im November 2023. Notion startete AI Q&A und sammelte fast sofort eine Warteliste von Millionen von Workspaces an. Ihre Vektordatenbank lief auf Pod-Clustern — Storage und Compute gebündelt, nach Workspace-ID geshardet. Innerhalb eines Monats näherten sie sich Kapazitätsgrenzen.
Anstatt unter Live-Traffic neu zu sharden, wählten sie den pragmatischen Weg: neue Index-Cluster hochfahren, die mit einer generation ID versehen sind, neue Workspaces auf frische Generationen routen und bestehende Workspaces an Ort und Stelle belassen. Zusammen mit Spark- und Airflow-Tuning bauten sie die Warteliste in vier Monaten ab. Die tägliche Onboarding-Kapazität stieg um das 600-Fache.
Sauberes Engineering unter Druck. Der Preis: Multi-Generation-Routing-Logik, die sie zwei Jahre lang begleiten sollte.
Dann zwei große Migrationen:
Mai 2024 — von der Pod-Architektur zu Serverless. Storage und Compute werden entkoppelt. Die Kosten sanken sofort um 50 %, und die Komplexität des Generation-Routings löste sich damit auf — weil Kapazität keine endliche Ressource mehr war, die im Voraus geplant werden musste.
Ende 2024 bis Anfang 2025 — von ihrem Serverless-Anbieter zu turbopuffer. Ihre Daten waren im proprietären Speichersystem eines Anbieters gespeichert, daher erforderte der Wechsel eine vollständige Neuindexierung. Sie nutzten die Gelegenheit, um auch ihr Embedding-Modell zu aktualisieren.
Mitte 2025: Sie lieferten Page State aus. Jede Textspanne wird mit xxHash (64-bit) gehasht und in DynamoDB gespeichert. Wenn eine Seite aktualisiert wird, vergleicht das System Hashes, bevor es entscheidet, ob erneut eingebettet werden soll. Wenn sich nur Metadaten geändert haben, patcht es die Vektordatenbank direkt, ohne den Vektor neu zu berechnen.
Kurz darauf verlagerte sich die Embedding-Erzeugung von Spark + external API zu selbst gehosteten Modellen auf Ray via Anyscale. CPU-Preprocessing und GPU-Inferenz laufen nun in einer einzigen Pipeline, wodurch die S3-Übergabe zwischen Systemen entfällt.
Zwei Jahre. Fünf große Wetten. Kosten um 90 % vom Höchststand gesenkt. Es ist ein wirklich beeindruckender Lauf.
Dies ist eine Geschichte, die Big Data bereits erzählt hat
Bei jedem Schritt wollte ich eine Zeitmarke dazuschreiben: Das Big-Data-Ökosystem hat dies in [Jahr] gelöst. Es ist kein Zufall. Dieselben Beschränkungen führen zu denselben architektonischen Schritten.
1. Storage-Compute-Trennung und Serverless: Für Arbeit zahlen, nicht für Existenz
Notions zwei Kostenmigrationen — von Pod-Clustern zu Serverless, dann zu einem auf Objektspeicher basierenden Serverless-Setup — lassen sich als ein architektonischer Schritt lesen: aufhören, für die bloße Existenz von Infrastruktur zu zahlen, und anfangen, für tatsächlich geleistete Arbeit zu zahlen. Ob ein Workspace aktiv abgefragt wurde oder wochenlang inaktiv war, das alte Modell ließ Cluster weiterlaufen und weiter Kosten verursachen.
So gesehen besteht die zentrale Veränderung darin, Storage von Compute zu entkoppeln: Indizes liegen im Object Storage, kalte Collections halten nahezu keine Compute-Ressourcen vor, heiße Collections werden bei Bedarf geladen, und die Kosten folgen der tatsächlichen Nutzung deutlich genauer. Im Big-Data-Bereich war dies nicht nur ein Wechsel von HDFS zu S3; es war eine breitere Bewegung von Storage-Compute-Integration hin zu Storage-Compute-Trennung.
Die Reihenfolge war entscheidend: Zuerst löste unabhängige Skalierung die Probleme von Elastizität und Kapazitätsplanung; anschließend senkten kurzlebige Compute-Ressourcen plus persistenter Object Storage die Nutzungskosten. Hadoops Standardbereitstellung platzierte Storage und Compute gemeinsam, um Datenlokalität zu erreichen, was unabhängige Skalierung erschwerte. Sobald die Daten nach S3 verschoben wurden, konnten Spark-Cluster pro Job hochgefahren und danach wieder heruntergefahren werden, während der Storage persistent blieb.
Der Trade-off ist ebenfalls strukturell. Der Zugriff auf Object Storage setzt eine Untergrenze für die Cold-Start-Latenz: mehrere GET-Requests, Deserialisierung und Indexrekonstruktion. Das ist weniger ein Problem der Parameteroptimierung als vielmehr ein Problem der Storage-Physik. Für Notions aktuellen Workload, bei dem die meisten Workspaces nur selten abgefragt werden, ist dies ein guter Trade-off. Doch je stärker die AI-Nutzung wird, desto schwerer lassen sich zwei Grenzen ignorieren: große Tenants mit dauerhaft hohem Abfragevolumen und Nutzer, die zu kalten Workspaces zurückkehren, bei denen Tail-Latenz für Nutzer sichtbar wird. An diesem Punkt reicht ein einstufiges S3-natives Caching oft nicht aus; warme Daten auf lokalen SSDs zu halten, wird wesentlich wichtiger.
2. Lambda Architecture: Echtzeit ist der Bedarf, Fragmentierung ist der Preis
Notions Indexierungssystem läuft über zwei Pfade: eine Offline-Spark-Pipeline für großflächige Backfills und Kafka-Consumer für Echtzeit-Updates. Das ist ein klassisches Lambda-Setup.
Wenn dir Datenaktualität wichtig ist, ist dieses Design ein naheliegender Ausgangspunkt. Das Problem zeigt sich später: Dieselbe Logik beginnt, sich über mehrere Systeme zu verteilen, und Teams verbringen mehr Zeit damit, die Pfade konsistent zu halten.
In Notions Fall erstreckt sich diese Aufteilung inzwischen über Spark, Kafka-Consumer, DynamoDB für Page State, Ray für Embedding und eine separate Serving-Schicht.
Jede Komponente erledigt die richtige Aufgabe. Die versteckte Abgabe ist die Integrationsfläche:
- mehr Glue Code
- mehr Zustandsübergaben
- mehr Möglichkeiten für Drift zwischen Offline- und Online-Verhalten
Vieles davon wird durch geschlossenen Storage für Serving verstärkt. Provider-Migration bedeutet vollständige Neuindexierung. Unterstützung für Partial Updates bedeutet externe Tracking-Tabellen. Offline-Verbesserungen helfen der Online-Retrieval erst dann, wenn ein weiterer Synchronisierungsschritt abgeschlossen ist.
Der Kern von Kappa ist einfach: ein Verarbeitungsmodell. Die stärkere Form ist One Engine - Batch und Streaming als zwei Modi eines Systems, nicht zwei zusammengeklebte Systeme.
Genau hier passt Lakebase hinein. Es bringt diese One-Engine-Idee auf ein lake-natives Fundament und überbrückt die OLTP/OLAP-Lücke, sodass Echtzeit-Updates, Online-Serving und Offline-Verarbeitung auf einer einzigen Tabelle laufen.
3. Die fehlende Schicht: Eine deklarative Schnittstelle für Vektoroperationen
Der Wechsel von Spark + einer externen Embedding-API zu einer einheitlichen Ray-Pipeline ist die richtige Entscheidung — zwei Systeme, die über S3 kommunizierten, in einem einzigen Compute-Graph zusammenzuführen, ist eine echte Vereinfachung, und die prognostizierte Reduktion der Embedding-Kosten um über 90 % spiegelt eine tatsächliche architektonische Verbesserung wider. Aber es ist eine Vereinfachung auf der Ebene der Infrastrukturverdrahtung, und was weiterhin fehlt, ist eine Vereinfachung auf semantischer Ebene.
In der Hadoop-Ära bedeutete es, für jede Datenaufgabe MapReduce-Jobs zu schreiben: Man musste den Lebenszyklus von Mapper und Reducer verstehen, wissen, wie der Shuffle funktionierte, wie man Fehler behandelt und wie man Stages verkettet. Hive fügte eine deklarative Schicht hinzu — man drückt in SQL aus, welches Ergebnis man möchte, und das System findet heraus, wie es dies in MapReduce-Ausführung übersetzt. Dieser Wandel machte die Dinge nicht nur schneller; er veränderte, wer überhaupt mit Daten arbeiten konnte, und brachte die Engineering-Kosten einer neuen Datenoperation viel näher an die Kosten des Schreibens einer Abfrage als an die Kosten des Schreibens eines verteilten Systems.
Vektor- und unstrukturierte Daten haben diese Schicht jedoch noch nicht.
- Wenn Sie einen Korpus aus einer Milliarde Vektoren vor einem Modelltrainingslauf deduplizieren möchten, schreiben Sie Spark-Jobs, wählen die richtigen Operatoren für Distanzberechnungen aus, verwalten Ausgabeformate und finden heraus, wie Sie die Ergebnisse dorthin zurückspeisen, wo Ihre Serving-Schicht läuft.
- Wenn Sie über Hunderte Millionen Dokumente hinweg von einem Embedding-Modell auf ein neueres upgraden möchten, bauen Sie eine Backfill-Pipeline, verwalten das gleichzeitige Bestehen alter und neuer Embeddings während der Umstellung und räumen anschließend auf — und dieser Prozess ist eher ein mehrmonatiges Engineering-Projekt als ein Routinevorgang.
- Wenn Sie komprimierten Benutzerspeicher über Sitzungen hinweg erhalten möchten, entwerfen Sie die Komprimierungslogik, verwalten versionierte Schreibvorgänge und verdrahten die Ausgabe von Hand mit dem Retrieval-Pfad. Jeder dieser Punkte ist eher ein Systems-Engineering-Projekt als eine Datenoperation.
Das deklarative Äquivalent wäre, die Absicht auszudrücken — „dedupliziere diese Sammlung mit einer Kosinus-Toleranz von 0,05 und schreibe die Ergebnisse zurück“, „führe ein Backfill der Embeddings mit diesem neuen Modell durch“, „komprimiere Interaktionsverläufe, die älter als 90 Tage sind, in dichte Speicherrepräsentationen“ — und das System Ausführungsplanung, Ressourcenmanagement und Konsistenz übernehmen zu lassen. Das ist die Schicht, die Context Engineering in großem Maßstab praktikabel macht, statt jedes Mal ein individuelles Engineering-Projekt daraus zu machen. Und sie fehlt in aktuellen Vektor-Infrastruktur-Stacks noch weitgehend, unabhängig vom Serving-Backend.
| Notions Entscheidung | Architekturmuster |
|---|---|
| Pod-Cluster → serverless → durch Objektspeicher gestütztes serverless | Storage-Compute-Trennung: Entkopplung des Lebenszyklus angewandt auf Vektorindizes |
| Dual-Path-Indexierung + Page State + Generation-Routing | Real-time-first-Lambda-Design: schnelle Aktualität, aber steigende Synchronisierungskosten über Online-/Offline-Pfade hinweg |
| Spark + S3-Handoff → Ray | Zusammenführen von I/O zwischen Systemen — aber die deklarative Schnittstellenschicht darüber fehlt weiterhin |
Big Data brauchte 15 Jahre, um sich auf eine Architektur zuzubewegen, in der Storage, Compute und Verarbeitungssemantik sauber getrennt und kombinierbar waren. Notion hat den größten Teil dieses Weges in zwei Jahren zurückgelegt, was wirklich beeindruckend ist. Das Stück, das noch nicht angekommen ist, ist jenes, das die nächsten zwei Jahre erheblich günstiger zu bauen machen würde.
Aber das ist erst Kapitel eins
Alles, was Notion gelöst hat, ist die Infrastruktur für ein AI-Feature.
All dieses Engineering — Generation-Routing, Provider-Migrationen, Page State, Ray-Compute-Vereinheitlichung — existiert, um AI Q&A gut, günstig und zuverlässig funktionieren zu lassen. Das haben sie geschafft. Die Infrastruktur für dieses eine Feature ist nun ausgereift. Notion wird nicht nur ein einziges AI-Feature ausliefern.
Drei Probleme, die ich in ihrem nächsten Engineering-Post erwarte
Problem 1: Die Obergrenze von Serverless + Cold/Hot-Trennung im großen Maßstab
Notions aktuelle Wahl ist ein guter Kompromiss für ihre derzeitige Workload: Millionen von Workspaces, von denen die meisten selten abgefragt werden, wo S3-native Wirtschaftlichkeit stark ist. Die Grenze besteht darin, dass Performance-Obergrenzen hier stärker durch das Verhalten von Objektspeichern als durch justierbare Software-Regler bestimmt werden.
Die S3-Latenz bis zum ersten Byte liegt oft im Bereich von 10–100 ms. Ein kalter Index kann mehrere GET-Anfragen und Deserialisierung erfordern, bevor er abfragbar ist. In der Produktion kann der p99-Wert für kalte Abfragen in Bereiche von mehreren Sekunden reichen. Das ist normalerweise kein Modellproblem; es ist Index-Warmup.
Die wichtigsten Schmerzpunkte sind vorhersehbar.
- Erstens beginnen große Tenants mit hohem, anhaltendem Abfragevolumen, die Grenzen von Single-Tier-Caching zu spüren.
- Zweitens können Nutzer, die zu kalten Workspaces zurückkehren, spürbare Latenzspitzen erleben. Multi-Tier-Caching (Arbeitsspeicher + lokale SSD + Objektspeicher) verändert diese Tail-Form auf Weisen, die Single-Tier-Designs normalerweise nicht können.
Das Abrechnungsmodell kann Teams ebenfalls überraschen: Die Abrechnung nach Namespace-Größe statt nach Query-Workload bedeutet, dass große Workspaces teuer wirken können, selbst wenn einzelne Queries nur kleine Teilmengen scannen. Bei verzerrten Multi-Tenant-Verteilungen können die Ausgaben von der Intuition auf Query-Ebene abweichen.
Filter-Recall ist ein weiteres latentes Problem bei ANN-plus-Post-Filter-Ansätzen. Wenn Filter eng gefasst sind — Seitentyp, Mitwirkende, Zeitraum — können Kandidatenpools zu klein werden, was zu einem Rückgang des Recalls führt. Je mehr gefilterte AI-Retrieval-Pfade Notion hinzufügt, desto häufiger tritt dieser Trade-off tendenziell auf.
Also ja, der aktuelle Trade-off ist gut. Die Grenzen sind nur klar: Große Tenants und Latenz bei Cold Queries werden zu den ersten Rissen.
Problem 2: Die Echtzeit-/Offline-Trennung wird immer teurer
Notions aktueller Stack: Spark + Airflow für Offline-Batch-Verarbeitung, Kafka-Consumer für Echtzeit-Updates, Ray für Embedding, Turbopuffer für Queries. Vier Systeme, jedes erledigt seine Aufgabe gut, alle arbeiten auf denselben zugrunde liegenden Daten — den Seiteninhalten der Nutzer.
Das ist die Daten-Silo-Struktur in ihrer klassischen Form. Dieselben Quelldaten werden von verschiedenen Systemen als mehrere Views gepflegt, wobei Logik auf Anwendungsebene dafür verantwortlich ist, sie synchron zu halten. Page States xxHash + DynamoDB existiert speziell, um die Konsistenz zwischen der Batch-Processing-View und der Echtzeit-View aufrechtzuerhalten. Diese Logik ist korrekt, aber ihre Komplexität skaliert linear mit der Anzahl der AI-Features — jedes neue Feature fügt einen weiteren Satz an Synchronisierungslogik hinzu, der über die Echtzeit- und Offline-Pfade hinweg gepflegt werden muss.
Das tiefere Problem: Offline-Verarbeitung kann Online-Serving nicht direkt verbessern ohne einen Synchronisierungsschritt. Wenn Notions Offline-Pipeline starke semantische Beziehungen zwischen Dokumenten in einem Workspace entdeckt, können diese Beziehungen das AI-Q&A-Retrieval nicht verbessern, bis die Ergebnisse an einen Ort geschrieben werden, den die Online-Query-Logik lesen kann. Dazwischen liegt eine Systemgrenze, verbunden mit Latenz und Konsistenzrisiko.
Das macht es so schwer, das Daten-Flywheel in Gang zu bringen: Signale, die durch Online-Nutzung entstehen, können Offline-Modelle nicht kontinuierlich verbessern, ohne in beide Richtungen eine Systemgrenze zu überschreiten.
Die architektonische Antwort ist OneData: Online-Serving und Offline-Verarbeitung teilen sich dieselbe zugrunde liegende Tabelle. Keine mehreren Views, die synchronisiert werden müssen, keine Konsistenzlogik auf Anwendungsebene. Eine Iceberg-Tabelle, verschiedene Compute-Modi, die am selben Ort lesen und schreiben. Die Offline-Schicht macht die Online-Schicht intelligenter; die Online-Schicht erzeugt Signale, die die Offline-Schicht verarbeitet. Das Flywheel läuft auf einem einzigen Fundament.
Problem 3: Offline Context Engineering — wo der echte Burggraben entsteht
Notion AI heute: Nutzer stellt eine Frage → relevante Chunks in Echtzeit abrufen → an das LLM übergeben → Antwort zurückgeben. Die Qualitätsobergrenze dieser Pipeline wird dadurch bestimmt, was im Index enthalten ist.
Die Lücke, die Offline Context Engineering schließt, ist nicht die Retrieval-Qualität zur Query-Zeit — sondern die Qualität dessen, was du vor dem Eintreffen der Query aufgebaut hast.
Memory. Jede Unterhaltung mit Notion AI enthält ein Signal: was dem Nutzer wichtig ist, wie er arbeitet, welches Wissen für ihn relevant ist. Dieses Signal zu vektorisieren und in abrufbarem User Memory zu organisieren, ist unkompliziert. Es zu pflegen ist es nicht: Alte Memories benötigen Kompression (eine Unterhaltung von vor sechs Monaten muss zu einer dichteren Repräsentation werden), veraltete Memories müssen aktualisiert werden (wenn neue Inhalte alten Aufzeichnungen widersprechen), und verwandte Memories müssen hierarchisch organisiert werden. All das ist kontinuierliche Offline-Batch-Verarbeitung über Vektordaten. Es kann nicht zur Query-Zeit erledigt werden.
Vorberechnete Wissensgraphen. Anstatt jedes Mal aufs Neue zu suchen, „welche Dokumente für diese Anfrage relevant sind“, kann die Offline-Verarbeitung ein Modell der semantischen Topologie des Arbeitsbereichs erstellen — welche Dokumente dieselben Konzepte behandeln, welche Entscheidungen Abhängigkeiten haben, wie sich Ideen im Laufe der Zeit entwickelt haben. Dieses Modell wird zum Kontext, den die KI bereits hat, sodass sie auf der Grundlage eines Verständnisses Ihres Arbeitsbereichs schlussfolgert, statt eine neue Suche von Grund auf durchzuführen.
Das Daten-Schwungrad. Welche Retrieval-Ergebnisse wurden verwendet? Welche Fragen tauchen immer wieder auf, ohne zufriedenstellende Antworten zu liefern? Welche Dokumente werden über verschiedene Anfragen hinweg wiederholt referenziert? Diese Signale können, offline verarbeitet, das Retrieval kontinuierlich optimieren — indem Chunking-Strategien angepasst, Wissen hervorgehoben wird, das sich immer wieder als relevant erweist, und blinde Flecken identifiziert werden. Das Schwungrad dreht sich nur, wenn es eine Infrastruktur gibt, die Signale in Verbesserungen in der Vektorschicht übersetzt. Ohne diese sind die Signale nur Bytes in einer Logdatei.
Notion sitzt auf einem der interessantesten KI-Datensätze, die es gibt: strukturiertes Wissen, bewusst organisiert, über zig Millionen Arbeitsbereiche hinweg. Das ist ein außergewöhnlicher Rohstoff. Aber ein Datenvorsprung entsteht nicht dadurch, dass man Daten hat — er entsteht dadurch, dass man eine Infrastruktur hat, die Daten kontinuierlich in Fähigkeiten verwandelt. Ihre aktuelle Vektorinfrastruktur ist für Online-Bereitstellung ausgelegt. Speicherpflege, Vorberechnung von Wissensgraphen, Schwungräder für Signalverarbeitung — das sind großskalige Batch-Probleme, die in der aktuellen Architektur keinen natürlichen Platz haben.
Lakebase-Positionierung
An diesem Punkt ist das Muster klar. Der nächste Engpass ist keine einzelne Entscheidung für eine Query Engine. Es ist die Lücke zwischen Echtzeit-Bereitstellung und Offline-Verarbeitung.
Vector Lakebase ist als Brücke positioniert:
Eine einheitliche Plattform für OLTP und OLAP: Echtzeit-Bereitstellung, iterative Entdeckung und Batch-Analysen laufen auf derselben lake-nativen Datengrundlage und einer einzigen Quelle der Wahrheit.
Ein inkrementeller Flow statt Dual-Path-Synchronisierung. Change Capture, Re-Embedding und Re-Indexing werden zu Fähigkeiten der Datenschicht, nicht zu Glue Code in der Anwendung.
Ein Ort, an dem Offline-Intelligenz online ankommt. Speicherkompression, Backfills und Qualitätssignale werden in dieselbe Tabelle zurückgeschrieben und verbessern die Bereitstellung direkt.
Das ist das praktische Kapitel 2: nicht nur bessere Suche, sondern ein einheitliches Betriebsmodell für Vektordaten.
Vector Lakebase ist die Antwort von Zilliz Cloud auf Kapitel 2: einheitliche Vektorspeicherung, -verarbeitung und -bereitstellung auf Ihrem bestehenden Data Lake. Keine Migration erforderlich. Bleiben Sie dran.
Weiterlesen
Zilliz Cloud Launches in AWS Australia, Expanding Global Reach to Australia and Neighboring Markets
We're thrilled to announce that Zilliz Cloud is now available in the AWS Sydney, Australia region (ap-southeast-2).
Vector Databases vs. Object-Relational Databases
Use a vector database for AI-powered similarity search; use an object-relational database for complex data modeling with both relational integrity and object-oriented features.
Vector Databases vs. Document Databases
Use a vector database for similarity search and AI-powered applications; use a document database for flexible schema and JSON-like data storage.