Databricks lleva la búsqueda de texto completo y vectorial a Lakebase Postgres

Databricks el 28 de septiembre de 2026, presentó Lakebase Search, un motor de búsqueda integrado para su base de datos Lakebase Postgres entregado a través de dos extensiones: lakebasevector para búsqueda de vecinos más cercanos aproximada y lakebasetext para búsqueda de texto completo BM25. Ambas extensiones están generalmente disponibles en AWS y Azure.

Las extensiones permiten a los desarrolladores ejecutar búsquedas semánticas, por palabras clave y híbridas directamente dentro de Postgres junto con los datos operacionales. Databricks dijo que los sistemas OLTP tradicionales no fueron diseñados para las demandas de búsqueda de los agentes de IA, que requieren recuperación de baja latencia y alta precisión y a menudo ejecutan búsquedas masivas en paralelo, y que resolver esto hasta ahora significaba conectar un motor de búsqueda independiente a la base de datos principal mediante un pipeline ETL. La compañía dijo que construyó Lakebase Search junto con la retroalimentación de cientos de clientes beta.

Resultados de la prueba de referencia y la implementación de Conexiom

Databricks dijo que lakebase_vector ofrece el doble del rendimiento del siguiente mejor sistema en la prueba de referencia VectorDBBench 100M, que utiliza el conjunto de datos LAION, y que es cuatro veces más barato que un proveedor de Postgres en la nube que usa pgvector, antes de los ahorros adicionales del escalado automático. La compañía informó una latencia P99 de 71 milisegundos con un recall del 97 %, lo que significa que el motor recuperó con éxito los verdaderos vecinos más cercanos el 97 % de las veces, y señaló que pgvector y DiskANN se probaron solo en una única instancia grande.

Databricks también informó un resultado de cliente de Conexiom, que ejecuta una búsqueda híbrida BM25 sobre más de 100 millones de filas con la mitad de la huella de cómputo de su configuración anterior de pgvector. Los costos de infraestructura de Conexiom se redujeron a un tercio y el rendimiento aumentó cinco veces en relación con pgvector, según la compañía.

“Lakebase Search nos brinda un nivel completamente nuevo de escalabilidad sobre pgvector, y desbloquea BM25 en la misma base de datos sin servidor,” dijo Jordan Voves, arquitecto de IA/ML en Conexiom. “Usamos Lakebase para conectar datos a nuestros agentes a gran escala.”

Los límites de Pgvector detrás del diseño

Databricks dijo que pgvector es la extensión más instalada en Lakebase Postgres, y describió tres puntos de dolor recurrentes observados en clientes que la ejecutan a gran escala.

El primero es el costo que escala con el volumen de datos en lugar de con el uso. pgvector mantiene su índice HNSW en la memoria de la base de datos y, dado que la búsqueda HNSW depende de la traversa aleatoria de grafos, el rendimiento disminuye entre 10 y 50 veces una vez que el índice se desborda al disco y las consultas se convierten en cadenas de lecturas aleatorias. Un vector float32 de 768 dimensiones ocupa aproximadamente 3,3 kilobytes de memoria una vez incluidos los enlaces del grafo y la sobrecarga de Postgres, por lo que un índice sobre 100 millones de filas requiere aproximadamente 330 gigabytes de RAM para permanecer residente, provisionado en su totalidad tanto si las consultas lo utilizan como si no.

El segundo es el mantenimiento del índice. Cuando una construcción se desbordó al disco, un índice pgvector tardó casi 50 horas en construirse en una instancia de nube estándar, según Databricks, y las escrituras sufren el mismo cuello de botella porque insertar un vector requiere una traversa aleatoria y la modificación de varias capas del grafo. Dado que HNSW no tiene reequilibrio global, recuperar la calidad de búsqueda implica ejecutar un REINDEX completo, una operación que bloquea la tabla y detiene las escrituras de producción.

El tercero es que una única consulta no puede paralelizarse. Una consulta pgvector es ejecutada por un solo proceso backend de Postgres, dejando el escaneo del índice HNSW sin paralelismo. Aumentar el recall requiere visitar más nodos del grafo, lo que añade lecturas de memoria aleatorias y comparaciones de distancia, inflando la latencia y reduciendo las consultas por segundo, por lo que escalar el rendimiento implica añadir conexiones a la base de datos o réplicas de lectura.

Cómo se construye Lakebase_vector

Lakebase Postgres separa el almacenamiento de la computación: los datos permanentes se encuentran en un almacenamiento de objetos en la nube de bajo costo, mientras que la RAM y el NVMe local sirven como cachés de corta duración que mantienen el conjunto de trabajo activo. Sobre esa base, Databricks combinó dos técnicas.

La agrupación jerárquica IVF agrupa vectores en clústeres almacenados como bloques contiguos. Una consulta puntúa los centroides de los clústeres en memoria, luego lee solo el pequeño número de bloques que parecen prometedores como lecturas secuenciales grandes en lugar de realizar muchos saltos aleatorios. La cuantización binaria, usando el método RaBitQ, comprime cada vector a aproximadamente un bit por dimensión, alrededor de 32 veces más pequeño que float32, de modo que las consultas escanean códigos compactos para preseleccionar candidatos y volver a clasificarlos solo contra los vectores de precisión completa.

Debido a que el diseño es sin estado, escala a cero, y en reposo los usuarios solo pagan por el almacenamiento. Databricks informó un P90 medido de 1,13 segundos para la primera consulta después de escalar a cero en un conjunto de datos de 100 millones de vectores, 768 dimensiones, y dijo que 100 millones de vectores pueden servirse en una unidad de cómputo Lakebase.

La construcción del índice entrena los centroides del clúster una sola vez con una pequeña muestra aleatoria; cada vector se asigna luego a su centroide más cercano, se cuantiza y se escribe en el bloque correspondiente como una operación independiente, de modo que el trabajo se distribuye entre todos los núcleos disponibles. Databricks dijo que su arquitectura LTAP delega la creación de índices de la base de datos principal a motores distribuidos como Spark, reduciendo los tiempos de construcción a minutos, y afirmó que se avecinan más mejoras en esa capacidad. Debido a que los predicados se aplican durante el escaneo del bloque, las consultas filtradas evitan la sobrecarga de candidatos y mantienen un alto recall, y una única consulta se paraleliza entre los núcleos de CPU.

Búsqueda de Texto BM25 y Consultas Híbridas

Databricks dijo que la búsqueda estándar tsvector de Postgres carece de contexto de relevancia a nivel de corpus. lakebase_text puntúa los términos utilizando la frecuencia inversa de documento global, otorgando mayor peso a términos raros y de alta intención y menos a palabras comunes de relleno. También verifica los límites superiores de puntuación al recorrer el índice, descartando bloques de postings completos que no pueden afectar el resultado top‑K, lo que la empresa afirmó que lo hace más rápido que tsvector con índices GIN.

Combinar las dos extensiones permite una búsqueda híbrida nativa dentro de Postgres: una única consulta puede aplicar predicados de filtro SQL habituales, unir tablas operativas en tiempo real y combinar la puntuación semántica de vectores con la relevancia de palabras clave BM25. Databricks dijo que el sistema escala de una fila a mil millones de vectores y de una consulta por segundo a miles sin reaprovisionamiento manual, describiendo el diseño como destinado a agentes de IA cuyos flujos de trabajo pueden generar miles de solicitudes de recuperación concurrentes en segundos.

Databricks posiciona Lakebase Search para usuarios que desean consolidar datos operacionales y de búsqueda en una única base de datos, mientras que Databricks AI Search sigue siendo su motor gestionado de recuperación listo para usar. Lakebase Search está disponible en general en AWS y Azure; los usuarios actuales de Lakebase pueden habilitar las extensiones, y los nuevos usuarios pueden registrarse en Lakebase.