Los ingenieros de Notion Preeti Gondi, Mickey Liu, Nathan Louie, Calder Lund y Jacob Sager publicaron un repaso detallado de cómo evolucionó la infraestructura de búsqueda vectorial de Notion desde el lanzamiento de Notion AI Q&A en noviembre de 2023. El titular: escalado por 10 junto con una reducción de costes del 90% en dos años.

Al lanzamiento, la ingesta funcionaba en dos vías: un pipeline batch offline con Apache Spark para trocear y vectorizar documentos existentes, y una vía online mediante Kafka para procesar ediciones de páginas casi en tiempo real. La base de datos vectorial corría sobre clústeres 'pod' dedicados, particionados por ID de workspace, de forma similar al esquema de sharding de Postgres en Notion. Apenas un mes después del lanzamiento, la demanda de una lista de espera de varios millones de workspaces llevó los índices al límite de capacidad. En lugar de un re-sharding incremental al estilo Postgres, Notion introdujo IDs de 'generación': cuando un conjunto de shards se acercaba a su capacidad, se aprovisionaba uno nuevo y los nuevos workspaces se enrutaban hacia él, evitando el tiempo de inactividad del re-sharding. Gracias a la programación con Airflow y al ajuste de los jobs de Spark, la capacidad diaria de incorporación aumentó 600 veces, los workspaces activos crecieron 15 veces y la capacidad de la base vectorial se expandió 8 veces, lo que permitió eliminar la lista de espera en abril de 2024.

En mayo de 2024, Notion migró de la arquitectura basada en pods a una arquitectura serverless que desacopla almacenamiento y cómputo, reduciendo los costes un 50% respecto al pico y eliminando los cuellos de botella de aprovisionamiento de capacidad. Como el gasto anual seguía siendo de varios millones, el equipo evaluó bases de datos vectoriales alternativas y, entre mayo de 2024 y enero de 2025, migró una carga de varios miles de millones de objetos a turbopuffer, un motor basado en almacenamiento de objetos que admite tanto despliegues gestionados como de tipo bring-your-own-cloud. La migración incluyó una reindexación completa, un modelo de embeddings actualizado, la eliminación de la lógica de sharding/generación (turbopuffer trata cada namespace como un índice independiente) y una transición gradual, generación por generación. Resultado: 60% menos gasto en el motor de búsqueda, 35% menos coste de cómputo en AWS EMR, y una latencia p50 de consultas que mejoró de 70-100ms a 50-70ms.

En julio de 2025, el 'Page State Project' abordó el reembebido redundante: antes, cualquier edición de una página -incluso de metadatos como los permisos- provocaba un rechunking y reembebido completos. El nuevo sistema almacena dos valores de hash xxHash de 64 bits por span (texto y metadatos) en DynamoDB, que se comparan en cada edición. Los cambios de solo texto reembeben únicamente los spans modificados; los cambios de solo metadatos (por ejemplo, actualizaciones de permisos) evitan por completo el reembebido y emiten en su lugar un comando PATCH, mucho más barato, a la base vectorial. Esto redujo el volumen de datos un 70%, abaratando tanto los costes de la API de embeddings como los de escritura en la base vectorial.

Desde julio de 2025, Notion está migrando su pipeline de embeddings casi en tiempo real de Spark/EMR a Ray sobre Anyscale, para resolver un problema de 'doble cómputo' (pagar tanto el preprocesamiento en Spark como las tarifas por token de la API de embeddings), la fiabilidad incierta de las API de embeddings de terceros y un sistema de pipelining propio y complicado creado para evitar límites de tasa. Ray permite a Notion alojar por sí mismo modelos de embeddings de código abierto, unificar preprocesamiento e inferencia en una sola capa de cómputo con pipelining GPU/CPU, y los espacios de trabajo gestionados de Anyscale permiten a los ingenieros usar herramientas como Cursor y VS Code sin aprovisionar infraestructura. Notion espera una reducción superior al 90% en los costes de infraestructura de embeddings gracias a esta migración, aún en curso. Para el embebido en el momento de la consulta, Ray Serve aloja modelos de código abierto en despliegues persistentes sobre GPU con batching y autoescalado configurables en YAML.

De cara al futuro, Notion planea conectar más fuentes de datos de terceros, seguir evaluando nuevos modelos de embeddings (gracias a la flexibilidad que ofrece Ray), continuar optimizando el pipeline y usar la búsqueda vectorial para impulsar los próximos 'Custom Agents', que obtendrán contexto del workspace y las aplicaciones conectadas de cada usuario.