turbopuffer separa los datos duraderos de los recursos que aceleran las consultas: conserva los datos en almacenamiento de objetos y utiliza memoria, NVMe y cómputo para atender búsquedas. Su ANN v3 describe una forma de escalar esa búsqueda vectorial; el rediseño turbopuffer v3 anunciado el 30 de septiembre de 2026 va más allá y convierte ANN en un índice secundario, en lugar de organizar el almacenamiento principalmente alrededor de él.
¿Cómo funciona una base de datos vectorial como turbopuffer?
Una base vectorial debe resolver dos necesidades que compiten: conservar un corpus de forma duradera y económica, y encontrar candidatos relevantes con rapidez. Según la descripción de arquitectura publicada por el cofundador de turbopuffer y actualizada el 5 de marzo de 2026, el servicio utiliza almacenamiento de objetos como fuente duradera y una capa de consulta sin estado que aprovecha memoria, NVMe y cómputo.
Almacenamiento duradero y caché
Los datos persistentes no tienen que permanecer íntegramente en memoria cara. Los nodos pueden cargar datos en caché al recibir solicitudes, de modo que la memoria y el SSD local ayudan a atender las consultas, mientras que el almacenamiento de objetos conserva la fuente duradera. La caché forma parte del diseño del rendimiento: una consulta caliente que encuentra sus datos en caché no representa la misma condición que una consulta fría que debe acceder a niveles más alejados.
Es una descripción del proveedor, no una auditoría independiente de cada despliegue. Para evaluar un sistema con este patrón, conviene preguntar qué datos se conservan en cada nivel, cómo se comportan las consultas frías y calientes y qué ocurre cuando la carga de trabajo cambia de localidad.
#1 Best Overall
De los documentos al índice
En el diseño vectorial inicial de turbopuffer, los documentos se almacenaban bajo direcciones derivadas del índice ANN. El historial técnico describe una evolución desde SPANN hasta SPFresh, que permite indexación incremental. La organización agrupa vectores, agrupa sus centroides y repite el proceso hasta formar una raíz. Así, grupos cercanos en el espacio vectorial pueden quedar organizados para leer datos contiguos y reutilizar partes superiores de la jerarquía.
¿Cómo escala la búsqueda vectorial?
Reducir candidatos y refinar resultados
En vez de comparar exhaustivamente cada consulta con todos los vectores, ANN busca de forma aproximada: primero reduce el espacio de candidatos y después refina los resultados. El artículo ANN v3, actualizado el 5 de mayo de 2026, combina agrupamiento jerárquico y cuantización binaria. Según turbopuffer, la cuantización comprime los vectores entre 16 y 32 veces y el reranking ayuda a conservar recall al refinar los candidatos.
La jerarquía de grupos encaja con la jerarquía de memoria: las partes superiores del árbol son útiles para dirigir la búsqueda y pueden reutilizarse, mientras que el acceso a grupos más específicos aporta detalle. La aproximación reduce el trabajo inicial; el refinamiento intenta recuperar precisión sin exigir una comparación completa con el corpus.
Qué significa la cifra de 100.000 millones
Turbopuffer reporta que su arquitectura ANN v3 alcanzó 100.000 millones de vectores, más de 1.000 consultas por segundo y 200 ms de latencia p99 en la carga que describe su artículo técnico. El ejemplo corresponde a 100.000 millones de vectores f16 de 1.024 dimensiones y a una arquitectura concreta; es un resultado publicado por el proveedor, no una garantía para cualquier conjunto de datos, hardware o despliegue.
Recommended Free Tools
Para distribuir esa carga, turbopuffer describe mantener el árbol completo en SSD, repartir fragmentos del índice entre máquinas con almacenamiento denso y difundir las consultas a los shards para combinar después sus resultados top-k. Añadir máquinas puede aumentar la capacidad, pero también eleva el coste de la distribución. Por eso el artículo sostiene que conviene mejorar primero la eficiencia de una máquina; no presenta la cifra como una comparación universal de coste o rendimiento.
¿Por qué turbopuffer anunció v3?
La publicación “RIP, vector database”, del 30 de septiembre de 2026, presenta turbopuffer v3 como una transición en curso. Su argumento central es que hacer del índice ANN la organización primaria puede limitar la eficiencia de otras consultas: según la empresa, ese diseño implica amplificación de almacenamiento y escritura y limita la vectorización.
| Diseño | Organización de documentos | Implicación descrita |
|---|---|---|
| Arquitectura anterior centrada en ANN | Documentos almacenados bajo direcciones derivadas del índice ANN. | El proveedor señala que esta disposición restringe la eficiencia de otras formas de consulta. |
| turbopuffer v3 anunciado | Rediseña la disposición, escritura, compactación y consulta de documentos e índices; ANN pasa a ser secundario. | El cambio busca dejar de organizar el almacenamiento alrededor de ANN como índice primario. La publicación de septiembre de 2026 lo describe como una transición, no como una migración completada para todos los clientes. |
La arquitectura anterior ya había admitido agregaciones, expresiones regulares, búsqueda difusa, vectores dispersos y ordenamiento por atributos, según esa misma publicación. El punto no es que esas consultas fueran imposibles, sino que el almacenamiento seguía centrado en ANN y, de acuerdo con la empresa, eso imponía límites de eficiencia.
Cómo leer los benchmarks publicados
La página de turbopuffer v3 describe benchmarks nocturnos del proveedor que comparan latencia p90 de v3 con v2 en namespaces de 10 millones de documentos en GCP us-central1. El cliente de prueba envía ocho consultas por segundo durante diez minutos. La metodología distingue dos condiciones:
- Caliente: se espera una tasa de aciertos de caché del 100%.
- Fría: se desactiva la caché.
Por tanto, una cifra de latencia tiene que leerse junto con la región, el tamaño del namespace, la tasa de consultas, la duración de la prueba y el estado de la caché. Son resultados de benchmarks publicados por turbopuffer con esa metodología; no equivalen a una garantía de servicio ni predicen por sí solos el rendimiento de una carga distinta.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.¿Qué cargas pueden encajar y cuáles conviene revisar?
La documentación de trade-offs de turbopuffer posiciona el producto para cargas de gran escala, muchos namespaces, datos particionados naturalmente por tenant, atención al coste, búsqueda híbrida BM25 más vectores y escrituras intensivas. Son criterios declarados por el proveedor, no una prueba de que el servicio sea la mejor opción para cada caso.
Aspectos que recomienda evaluar
- Durabilidad y caché: dónde reside la fuente duradera y qué coste y capacidad de caché exige la latencia objetivo.
- Perfil de consultas: latencia fría frente a caliente, búsqueda híbrida BM25 más vector y necesidad de agregaciones, filtros u ordenamiento por atributos.
- Escrituras: ritmo de indexación incremental y comportamiento de la compactación.
- Partición: número de namespaces, límites aplicables y si los datos se dividen de forma natural por tenant.
- Resultados: si la aplicación necesita reranking de segunda etapa integrado. La documentación indica que turbopuffer no lo ofrece integrado y recomienda hacerlo en la propia aplicación.
- Despliegue y controles: si la modalidad VPC/BYOC y las condiciones de seguridad disponibles se ajustan a los requisitos del equipo.
Cuándo mirar otras opciones
Según esa documentación, turbopuffer puede ser menos adecuado para proyectos pequeños, equipos que necesiten un nivel gratuito o software de código abierto, y cargas que requieran reranking de segunda etapa integrado. Estas son advertencias publicadas por el proveedor; la decisión depende de los requisitos concretos y de validar el comportamiento con la propia carga.
El origen del diseño, según la compañía
En su relato sobre el origen del servicio, el cofundador Simon Hørup Eskildsen explica que el proyecto nació de la necesidad de añadir recomendaciones y búsqueda semántica a Readwise Reader sin que el coste de infraestructura impidiera esa función. La publicación del 30 de septiembre de 2026 cita a Cursor y Notion como clientes tempranos. Tanto la historia como esas referencias proceden de la compañía y no constituyen validación independiente de rendimiento o adopción.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
