La empresa detrás de turbopuffer, una base de datos vectorial sin servidor que se lanzó hace años como una herramienta de búsqueda especializada, ha anunciado que está reconstruyendo todo su producto principal desde cero. Lo está contando a todo el mundo. El cambio, que la empresa denomina “turbopuffer v3”, hará que la búsqueda sea más rápida en general, incluido el vector de búsqueda, y sentará las bases para consultas SQL más rápidas también. La empresa no es sutil sobre lo que está eliminando; llama al diseño antiguo con un nombre directo: RIP, base de datos vectorial.
Esta revelación se distingue de lo que suelen hacer la mayoría de las empresas. Típicamente, las empresas guardan su arquitectura interna con celo, particularmente durante una reescritura de las bases. Pero turbopuffer ha elegido abrir las puertas y dejar que los seguidores observen el proceso a medida que ocurre. La actualización inicial describe los cimientos al rastrear la historia del producto, desde su primera versión hasta el día de hoy.
De ID y Vector a Todo Lo Demás
Cuando turbopuffer se lanzó como versión 1, los documentos eran simples: un ID y un vector. El vector representaba significado, y el ID apuntaba a él. La arquitectura de almacenamiento se construyó alrededor de un índice de agrupamiento jerárquico, comenzando con SPANN y luego migrando a SPFresh para admitir la indexación incremental. Los vectores se agruparon en clústeres, cuyos centroides se agrupaban nuevamente, formando un árbol con una única raíz.
En el anuncio, la empresa expuso el diseño completo, con el centroide raíz en la cima y ramas descendentes que llegan a través de niveles de centroides hoja, cada uno dirigiendo hacia sus propios vectores. Cada agrupación recibe un ClusterId, y cada elemento dentro de un grupo recibe un LocalId. Unidos, estas dos etiquetas forman lo que la empresa se refiere como la dirección ANN — el identificador principal para todo el arreglo.
La búsqueda vectorial sobre el almacenamiento de objetos funcionó sin problemas al principio, pero el sistema alcanzó sus límites rápidamente. Una vez que los clientes comenzaron a solicitar la capacidad de agregar valores de atributos y filtrar las búsquedas en función de esos atributos, turbopuffer se encontró necesitando construir un índice invertido. Este índice conecta un valor de atributo con las direcciones ANN de los documentos que lo contienen. La compañía presentó varios ejemplos de cómo funciona esto.
K::AttrIndex("family", "Alcidae") -> vec![C0L3, C1L2, C1L3, ...]
K::AttrIndex("genus", "Fratercula") -> vec![C0L3, C1L2, C1L9, ...]
Los postings mismos se convirtieron en el punto de partida para la búsqueda de texto completo en lugar de los documentos a los que apuntaban. Una consulta localizaría los postings que contienen su término, y luego se agregaban metadatos junto con esos postings para habilitar la puntuación BM25, incluyendo conteos de términos y longitudes de documentos. Aquí hay otra ilustración:
La llamada K::FTS(«description», «Atlantic») produce un vector con pares, cada uno conteniendo un identificador como C0L0 o C9L4 seguido por dos valores, incluyendo 2, 37, 1 y 42. La segunda línea, K::Attr(C0L0, «description»), produce un solo resultado de «Un ave marina de color negro y blanco de aspecto elegante con un pico enorme y multicoloreado, el frailecillo atlántico a menudo se le llama el payaso del mar. Se reproduce en madrigueras en islas del Atlántico Norte y pasa el invierno en el mar.».
Por qué el Diseño Antiguo Se Mantuvo
El índice primario construido alrededor del diseño ANN demostró ser altamente efectivo para la búsqueda ANN en el almacenamiento de objetos. La compañía desde entonces ha ampliado esa arquitectura para soportar índices únicos que contienen más de 100 mil millones de vectores, entregando lecturas p99 de 200 milisegundos mientras maneja más de 1,000 consultas por segundo. Debido a esto, cualquier alteración importante conlleva un riesgo real de degradar el rendimiento de ANN.
El diseño mantuvo a la empresa por debajo del nivel en lo que respecta a las formas de consulta no vectoriales que admite. Tres problemas importantes destacan: la expansión del almacenamiento, la expansión de la escritura y la vectorización limitada.
El contenido total de cada documento se encuentra debajo de su dirección ANN, lo que causa una amplificación del almacenamiento. Con solo un vector, los datos no vectoriales se almacenan solo una vez, junto con él. Pero cuando un documento tiene múltiples vectores —a través del anidamiento de documentos o interacción tardía— la empresa debe duplicar esos contenidos para cada vector en cambio. Esta duplicación explica algunas de sus restricciones más lamentables.
SPFresh puede reequilibrar vectores siempre que se agrega, cambia o elimina un documento, para mantenerlos bien agrupados. Dado que todos los datos del documento se almacenan utilizando la dirección ANN del vector del documento como clave, ese reequilibrio mueve todo el contenido del documento junto con cualquier índice invertido (de atributo y FTS) que apunte a él.
El Nuevo Índice Primario
La empresa está trasladando su índice principal a uno nuevo, manteniendo ANN «simplemente otro» como un índice de soporte. Este acuerdo ha limitado cómo funcionan ciertos planes de consulta, como GROUP BY y agregaciones. La empresa ha llevado el diseño vector-primario lo más lejos posible, y ahora está lista para el cambio.
Este cambio acelera la búsqueda en general, incluyendo la búsqueda de vectores, para turbopuffer. También sienta las bases para trasladar muchos más comandos SQL a turbopuffer y ejecutarlos a toda velocidad. El anuncio presenta el movimiento como un paso lógico hacia adelante desde turbopuffer v1 a v2, utilizando la adición de dos nuevos planes de consulta —filtrado de atributos y búsqueda de texto completo— para marcar el paso.
Turbopuffer impulsa a los clientes más antiguos de la empresa, incluyendo Cursor y Notion, validando el valor de estos compromisos. El motor de sincronización de Linear para tareas que no implican búsqueda, mientras que el motor de consultas ha crecido para acomodar todos estos planes de consulta. El diseño de almacenamiento, sin embargo, ha permanecido en gran medida igual.
Lo Que la Empresa Está Construyendo Próximamente
La empresa está migrando a su nuevo índice principal ahora. La declaración inicial explica el razonamiento detrás del movimiento por completo. La empresa considera un prospecto agradable abrir las puertas y permitir que los seguidores se unan.
La comparación a continuación muestra las dos arquitecturas en paralelo.
| Arquitectura | Índice Primario | Limitación Clave |
|---|---|---|
| Antiguo (vector-primary) | Índice vectorial ANN | Amplificación de almacenamiento, amplificación de escritura, vectorización limitada |
| Nuevo (no especificado) | Primario no especificado | No declarado |
Desde sus inicios, la empresa ha lanzado varios sistemas de indexación y herramientas de consulta adicionales, incluyendo agregaciones, búsqueda de expresiones regulares, coincidencia aproximada, búsqueda vectorial dispersa y ordenación por atributos — todos construidos con el mismo diseño de almacenamiento basado en vectores en su núcleo. El índice primario ANN se ha mantenido en gran medida sin cambios hasta ahora por una razón simple: funciona realmente, realmente bien para la búsqueda ANN en almacenamiento de objetos.
Nuestra opinión sobre el anuncio
La empresa ha expuesto los gastos asociados a su diseño anterior y los motivos para alejarse de él. También ha sido inusualmente abierta sobre las limitaciones que moldearon su elección.
La empresa está apostando por la nueva arquitectura para ofrecer consultas SQL más rápidas sin sacrificar el ritmo de la búsqueda vectorial. Es una apuesta arriesgada. La empresa admite el peligro de una regresión en el rendimiento de ANN, una señal de que la reestructuración del código está lejos de ser simple.
Los clientes de la empresa ya están utilizando turbopuffer para fines distintos a la búsqueda, incluyendo el motor de sincronización de Linear. La empresa ha lanzado varias otras estructuras de índice y motores de consulta desde sus inicios: agregaciones, búsqueda de regex, coincidencia borrosa, búsqueda vectorial dispersa y ordenación por atributos — todos construidos en torno al mismo diseño de almacenamiento vector-primario.
La declaración muestra a la empresa mirando más allá de los límites de su producto existente. El nuevo índice principal gestionará muchas más consultas SQL que antes.
El sistema ha sido adoptado por usuarios iniciales como Cursor y Notion, y actualmente está siendo utilizado por Linear para impulsar su motor de sincronización. El rendimiento ANN actual se sitúa en más de 100 mil millones de vectores, con tiempos de lectura de 200 ms p99 y soportando un rendimiento de 1,000+ consultas por segundo. Sus capacidades de consulta incluyen búsqueda de vectores, filtrado de atributos, búsqueda de texto completo, agregaciones, búsqueda de regex, coincidencia difusa, búsqueda de vectores dispersos y ordenamiento de atributos.
Esta empresa se encuentra en medio de un cambio. El informe inicial explica el razonamiento detrás del cambio por completo. La firma considera agradable abrir sus puertas y permitir que los seguidores se unan. La firma ha llevado su diseño primario de vectores a sus límites, y ahora es hora de avanzar más.
Números concretos
- Diseño antiguo: Índice de vectores ANN como primario
- Escala ANN actual: Índices únicos que soportan más de 100 mil millones de vectores
- Latencia de lectura: 200 ms p99
- Rendimiento: 1,000+ consultas por segundo
- Nuevo diseño: Primario no especificado con ANN como secundario
- Capacidades de consulta: Búsqueda de vectores, filtrado de atributos, búsqueda de texto completo, agregaciones, búsqueda de regex, coincidencia difusa, búsqueda de vectores dispersos, ordenamiento de atributos
Material fuente: “RIP, vector database,” turbopuffer.com.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.