Die Notion-Ingenieure Preeti Gondi, Mickey Liu, Nathan Louie, Calder Lund und Jacob Sager veröffentlichten eine ausführliche Rückschau darauf, wie sich die Vektorsuche-Infrastruktur von Notion seit dem Start von Notion AI Q&A im November 2023 entwickelt hat. Die Kernaussage: 10-fache Skalierung bei gleichzeitig 90% geringeren Kosten über zwei Jahre.
Beim Start lief die Ingestion über zwei Pfade: eine Offline-Batch-Pipeline mit Apache Spark für das Chunking und Einbetten bestehender Dokumente sowie einen Online-Pfad über Kafka für nahezu Echtzeit-Seitenbearbeitungen. Die Vektordatenbank lief auf dedizierten 'Pod'-Clustern, gesharded nach Workspace-ID ähnlich dem Postgres-Setup von Notion. Bereits einen Monat nach dem Start stieß die Nachfrage einer mehrere Millionen Workspaces umfassenden Warteliste die Indizes an ihre Kapazitätsgrenzen. Statt eines Postgres-artigen inkrementellen Re-Sharding führte Notion 'Generation'-IDs ein: Näherte sich ein Shard-Satz der Kapazitätsgrenze, wurde ein neuer Satz bereitgestellt und neue Workspaces dorthin geroutet, ohne Ausfallzeiten durch Re-Sharding. Durch Airflow-Scheduling und Spark-Tuning stieg die tägliche Onboarding-Kapazität um das 600-Fache, die Zahl aktiver Workspaces um das 15-Fache und die Vektordatenbank-Kapazität um das 8-Fache – bis April 2024 war die Warteliste abgearbeitet.
Im Mai 2024 wechselte Notion von der Pod-Architektur zu einer Serverless-Architektur, die Speicher und Rechenleistung entkoppelt, was die Kosten um 50% gegenüber dem Spitzenwert senkte und Engpässe bei der Kapazitätsplanung beseitigte. Da die jährlichen Kosten weiterhin im Millionenbereich lagen, evaluierte das Team alternative Vektordatenbanken und migrierte zwischen Mai 2024 und Januar 2025 die aus mehreren Milliarden Objekten bestehende Arbeitslast zu turbopuffer, einer auf Objektspeicher basierenden Engine mit sowohl gemanagten als auch Bring-your-own-Cloud-Deployments. Die Migration umfasste eine vollständige Neuindizierung, ein aktualisiertes Embedding-Modell, den Wegfall von Sharding-/Generation-Logik (turbopuffer behandelt jeden Namespace als eigenständigen Index) und eine schrittweise Umstellung Generation für Generation. Ergebnis: 60% geringere Ausgaben für die Suchengine, 35% geringere AWS-EMR-Rechenkosten und eine Verbesserung der p50-Abfragelatenz von 70-100ms auf 50-70ms.
Im Juli 2025 adressierte das 'Page State Project' redundantes erneutes Embedding: Zuvor löste jede Bearbeitung einer Seite – selbst Metadaten wie Berechtigungen – ein vollständiges erneutes Chunking und Embedding aus. Das neue System speichert pro Span zwei 64-Bit-xxHash-Werte (Text und Metadaten) in DynamoDB und vergleicht sie bei jeder Bearbeitung. Reine Textänderungen embedden nur die geänderten Spans neu; reine Metadatenänderungen (z. B. Berechtigungsupdates) überspringen das Embedding komplett und lösen stattdessen einen günstigeren PATCH-Befehl an die Vektordatenbank aus. Das senkte das Datenvolumen um 70% und damit sowohl die Kosten für die Embeddings-API als auch für Schreibvorgänge in der Vektordatenbank.
Seit Juli 2025 migriert Notion seine nahezu in Echtzeit laufende Embeddings-Pipeline von Spark/EMR zu Ray auf Anyscale, um ein 'Double-Compute'-Problem (gleichzeitige Kosten für Spark-Vorverarbeitung und nutzungsbasierte Embedding-API-Gebühren), unzuverlässige Embedding-APIs von Drittanbietern und umständliches selbstgebautes Pipelining zur Vermeidung von Rate Limits zu lösen. Ray erlaubt es Notion, Open-Source-Embedding-Modelle selbst zu hosten, Vorverarbeitung und Inferenz auf einer einzigen Recheninfrastruktur mit GPU/CPU-Pipelining zu vereinen, und die verwalteten Workspaces von Anyscale erlauben Ingenieuren die Nutzung von Tools wie Cursor und VS Code ohne eigene Infrastrukturbereitstellung. Notion erwartet dadurch eine Kostensenkung von über 90% bei der Embeddings-Infrastruktur; die Migration läuft noch. Für das Embedding zur Abfragezeit hostet Ray Serve Open-Source-Embedding-Modelle in dauerhaften GPU-Deployments mit konfigurierbarem Batching und Autoscaling, definiert in YAML.
Für die Zukunft plant Notion, weitere Drittanbieter-Datenquellen anzubinden, laufend neue Embedding-Modelle zu evaluieren (ermöglicht durch die Flexibilität von Ray), die Pipeline weiter zu optimieren und die Vektorsuche für die kommenden 'Custom Agents' zu nutzen, die Kontext aus dem Workspace und verbundenen Apps eines Nutzers ziehen.