Hay noticias que parecen internas de un vendor y terminan anunciando un cambio de época. Esta semana turbopuffer — el motor de búsqueda que usan Cursor, Notion y Linear — publicó una entrada de blog con un título que no deja margen a la interpretación: RIP, vector database. Están demoliendo su arquitectura v1/v2, donde el índice ANN de vectores era el centro del universo, para pasar a un diseño donde los vectores son un índice secundario más. Ni más ni menos que eso.
Por qué importa si no usas turbopuffer
Porque el patrón es lo que importa, no el producto. Durante 2023 y 2024 la industria se mareó con las «vector databases» como categoría separada: Pinecone, Milvus, Weaviate, Qdrant, y un infierno de wrappers. La idea era que tus embeddings eran tan especiales que merecían su propio motor. Cuatro años después, la realidad dijo otra cosa: Postgres con pgvector sirve para la mayoría de los casos, y los motores de búsqueda serios terminaron absorbiendo los vectores como una feature más, no como su razón de ser.
El post de turbopuffer es honesto sobre por qué el diseño vector-primario se les quedó corto: amplificación de escritura (mover un vector rebalanceaba todo el documento y sus índices), duplicación de datos cuando un documento tiene varios vectores, y planes de consulta que no pueden vectorizar bien porque todo queda atado a clusters de 100-200 documentos. Traducción al español de la calle: hacer del vector el centro de la infraestructura era una mala decisión de arquitectura, y nadie lo quiso decir en voz alta mientras la fiebre RAG estaba en su peak.
Lo que aprendí pagando la cuenta
Lo digo con cicatrices. En 2024 monté un pequeño stack de embeddings para buscar en mis propias notas y logs. Le puse una vector DB dedicada con todo el ceremonial: colección, dimensiones, distancia coseno, el pack completo. A los dos meses me di cuenta de que tenía dos bases de datos que mantener, dos respaldos que coordinar, y que el 90% de mis consultas en realidad filtraban por fecha o por tag antes de buscar similitud. En otras palabras: los metadatos mandaban, no los vectores. Migré todo a una sola tabla con una columna de embeddings y un índice invertido, y el sistema se volvió más simple, más barato y más fácil de respaldar.
Es una versión en miniatura de exactamente lo mismo que turbopuffer explica con benchmarks: cuando tu caso de uso real es «buscar con filtros y ordenar», el vector es solo una señal más, y la base de datos general (o el motor de búsqueda general) gana. La especialización extrema solo paga cuando tu escala es tan absurda que cada micro-optimización vale millones.
La lección que me llevo
Estos ciclos de hipe técnico dejan siempre el mismo rastro: una categoría de producto que nace como innovación y muere como feature. Primero fue el «data warehouse en la nube», después las «vector databases», mañana quién sabe. Cuando veas una nueva categoría de infraestructura vendida como imprescindible, pregúntate si es un producto o una feature esperando a ser absorbida. Si tu caso de uso es modesto — y el de la mayoría de nosotros lo es — la respuesta honesta es casi siempre la base de datos que ya tienes, con una extensión.
Y ojo con la ironía final: turbopuffer creció precisamente por ser anti-hipe — object storage barato en vez de appliances caros, sin RAM costosa de por medio. Que ahora ellos mismos bajen el vector del altar es la mejor señal de que la era de la vector DB como producto terminó. Los embeddings quedan, claro. Lo que muere es el negocio de tratarlos como ciudadanos de primera clase con ciudad propia.
Fuente: RIP, vector database, turbopuffer.
Fuente de inspiración: RIP, vector database
