Presentamos Lakebase Search: recuperación nativa para agentes integrada en Lakebase Postgres

Hoy presentamos Lakebase Search: recuperación híbrida de vectores y texto completo integrada en Lakebase, ya disponible en versión beta en AWS y Azure. Impulsado por dos extensiones nativas de Postgres, lakebase_vector y lakebase_text, permite que todo el bucle de tus agentes dependa de un único backend de datos, un lakebase.

Esto aporta una escala de nivel superior, una rentabilidad sin precedentes y una ergonomía diseñada especialmente para agentes.

Los agentes transforman la búsqueda en un flujo de trabajo operativo: recuperan contexto, razonan, actúan y recuerdan. Esto conecta profundamente la ruta de lectura (recuperación) con la ruta de escritura (memoria), lo que hace que la recuperación instantánea sea esencial para acceder a información recién generada en tiempo real.

Hasta ahora, ese bucle no tenía un entorno nativo de Postgres diseñado para la escala y la rentabilidad que exige la búsqueda a gran escala.

Para los agentes, la búsqueda es en realidad una carga de trabajo operativa

Los agentes ahora operan 4 veces más bases de datos en Lakebase que los usuarios humanos, y su requisito principal es completamente diferente al de un humano. Los motores de búsqueda tradicionales asumen una instantánea de lectura exclusiva de datos desactualizados. Los agentes, sin embargo, tratan la búsqueda como una base de datos operativa activa.

Observa un esquema de agente típico: los documentos fragmentados y los embeddings viven directamente junto a un registro de memoria conversacional activo. Esto crea un bucle continuo de lectura y escritura. Los agentes escriben nuevos aprendizajes en la memoria en un turno y necesitan que esos mismos datos estén completamente indexados y listos para buscar en el siguiente. No solo necesitan una recuperación rápida; necesitan una búsqueda instantánea en las últimas escrituras absolutas.

La búsqueda es una carga de trabajo peculiar

La búsqueda es una carga de trabajo única con dos propiedades definitorias.

Primero, almacenas muchísimos más datos de los que realmente consultas, lo que deja a la mayoría de ellos inactivos (cold).

Segundo, la búsqueda de vectores provoca una gran saturación de datos. Un archivo de texto de 1 KB se expande al vectorizarse. Esto se debe a que el documento se divide en múltiples fragmentos (chunks), y cada fragmento genera un embedding de alta dimensión distinto, incluso antes de tener en cuenta la sobrecarga del índice.

Cuando esto se multiplica en miles de inquilinos (tenants) que en su mayoría están inactivos, las arquitecturas de búsqueda tradicionales fallan. Los índices de vectores estándar del sector, como HNSW, están limitados fundamentalmente por la memoria (memory-bound). Dado que el recorrido rápido de grafos depende en gran medida de que el índice permanezca residente en la RAM, alojar datos inactivos de múltiples inquilinos resulta costoso.

La búsqueda necesita un lakebase

El año pasado presentamos Lakebase: una arquitectura OLTP de Postgres sin servidor (serverless) donde los datos residen en un almacenamiento de objetos en la nube económico, pero una caché por niveles (RAM, NVMe local, pageserver) garantiza que las páginas activas (hot) se lean con la latencia de un disco local.

Nos dimos cuenta de que esta es exactamente la arquitectura que necesita la búsqueda moderna. Pero había un inconveniente: para aprovechar realmente esta rentabilidad sin destruir la velocidad de las consultas, se necesita un diseño de índice diseñado explícitamente para residir en una jerarquía de almacenamiento por niveles. Lakebase no tenía uno. Así que lo creamos.

Al combinar una arquitectura por niveles con un índice por niveles diseñado a medida, logramos:

• Escala de nivel superior sin penalización de velocidad: Al recuperar de forma inteligente solo las páginas requeridas desde el almacenamiento de objetos a una caché local, las instancias de Postgres más pequeñas logran la misma recuperación (recall) y latencia sin requerir recursos de computación masivos.
• Rentabilidad de nivel superior: La cola inactiva (cold) de vectores se encuentra en un almacenamiento de objetos casi gratuito, mientras que el conjunto de trabajo activo (hot) reside en NVMe. Pagas por lo que consultas, no por lo que almacenas.

La rentabilidad se ve más fácilmente en una tabla. Por terabyte al mes, según los precios de lista de la nube:

Nuestro método de indexación permite que Lakebase mantenga únicamente el conjunto de trabajo activo en la RAM. La mayoría inactiva descansa en el almacenamiento de objetos, lo que hace que el sistema sea dos órdenes de magnitud más económico, al tiempo que ofrece la búsqueda de alto rendimiento que tu aplicación realmente requiere.

Llevamos índices de búsqueda nativos de lagos de datos a Postgres.

Al crear Lakebase Search, nos centramos en dos propiedades no negociables.

Al crear Lakebase Search, teníamos dos requisitos estrictos: tenía que ser 100 % nativo de Postgres (reutilizando los tipos estándar pgvector/tsvector y las herramientas del ecosistema) y la indexación tenía que crearse desde cero para el almacenamiento de objetos en la nube por niveles.

Para lograrlo, hoy lanzamos dos nuevas extensiones de Postgres en versión Beta. Ambas comparten el mismo objetivo: ofrecer una relevancia de búsqueda de vanguardia sin obligarte a sobredimensionar la RAM.

1. lakebase_vector: compresión de 32x y escala de más de 1000 millones.

Conservamos los tipos de datos y operadores estándar de pgvector, pero cambiamos el tipo de índice subyacente. Dado que los datos permanecen en el formato nativo de pgvector, mantienen la compatibilidad y se pueden exportar a otros sistemas. Al agrupar y comprimir vectores mediante RaBitQ (Randomized Binary Quantization), reducimos el tamaño del índice 32 veces mientras mantenemos una alta recuperación (recall). Un índice de 100 millones de vectores que antes requería 300 GB of RAM ahora cabe en menos de 10 GB. Esta huella de memoria reducida permite que un solo índice se escale a más de 1000 millones de vectores. El conjunto de trabajo activo se almacena en caché en el NVMe local, mientras que la cola inactiva reside en el almacenamiento de objetos.

2. lakebase_text: BM25 real sin la saturación de memoria de GIN.

Postgres maneja la coincidencia exacta de palabras clave a través de índices GIN, que deben permanecer residentes en la RAM para mantener el rendimiento. Esta arquitectura hace que los costos de memoria se escalen linealmente con el tamaño del conjunto de datos.

lakebase_text reemplaza GIN con un índice optimizado para lecturas secuenciales desde el almacenamiento de objetos en la nube. Introduce la clasificación de relevancia BM25 nativa en Postgres sin la huella de RAM asociada.

Debido a que ambas extensiones se ejecutan dentro del mismo motor, la búsqueda híbrida se ejecuta en una sola consulta SQL. La similitud de vectores y la relevancia de las palabras clave se combinan mediante la fusión de rangos recíprocos (RRF), lo que permite unir y filtrar los resultados con las tablas operativas.

Postgres está listo para cargas de trabajo de búsqueda serias y a gran escala

Evaluamos Lakebase Search en LAION-100M (100 millones de vectores de 768 dimensiones, recuperación de los 10 mejores resultados, en una sola instancia). El rendimiento de las consultas con una caché activa (warm) y una sola conexión ofrece una recuperación exacta de los vecinos más cercanos sin ninguna saturación:

Lograr esta escala tradicionalmente requiere una arquitectura limitada por la memoria (memory-bound). Un índice HNSW estándar de pgvector requiere que el grafo de vecinos y sus páginas de montón (heap pages) de destino permanezcan residentes en la RAM para un recorrido eficiente. Con 100 millones de vectores:

1. pgvector: Requiere una instancia de 512 GB (64 CPU). La creación del índice tarda aproximadamente 40 horas. Debido a que el recorrido del grafo depende de un acceso aleatorio no localizado, los reinicios en frío causan grandes latencias de lectura de disco, lo que hace que la primera consulta tarde minutos.
2. lakebase_vector: Se ejecuta en una instancia de 192 GB (96 CU / 24 CPU). La creación del índice tarda 1.5 horas. Aunque el recorrido sigue siendo de acceso aleatorio, el diseño del índice agrupa los datos de modo que las búsquedas aleatorias se localicen dentro de un conjunto de trabajo activo en la caché NVMe, dejando la cola inactiva en el almacenamiento de objetos. La instancia se escala a cero cuando está inactiva; la primera consulta con caché en frío tarda 1.13 segundos.

Esta arquitectura cambia la forma de abordar el costo total de propiedad. La búsqueda heredada requiere un costo base fijo independientemente del volumen de consultas, mientras que Lakebase realiza un seguimiento del uso real:

Lakebase Search permite una ergonomía centrada en los agentes

Un único backend para memoria y contexto:

Los agentes no deberían tener que combinar una base de datos vectorial para el contexto y una base de datos transaccional para la memoria. Al integrar la lógica de recuperación directamente en la base de datos, todo el bucle del agente se ejecuta en un único backend. Dado que Lakebase Search es Postgres (reutilizando por completo los tipos estándar pgvector y tsvector), se conecta de forma nativa a sus MCP, controladores estándar y conectores existentes. Y lo que es más importante, como la búsqueda se encuentra junto a sus datos operativos, puede ejecutar una búsqueda híbrida, realizar un join con las tablas de su aplicación y filtrar de forma segura por inquilino, todo en una sola consulta SQL.

Experimentación continua de búsqueda

Optimizar las estrategias de fragmentación (chunking) o los pesos híbridos requiere prueba y error. En lugar de exportar datos a sistemas por lotes (batch) externos para su procesamiento, Lakebase Search se conecta con el Lakehouse para crear un bucle de retroalimentación estrecho. Puede ramificar conjuntos de datos de varios terabytes al instante y sin costo alguno, crear índices fuera de banda mediante cómputo en paralelo y enviar la retroalimentación del agente de vuelta al Lakehouse para su evaluación sin conexión.

Un motor de recuperación dedicado por agente

Las arquitecturas tradicionales requieren compartir un único clúster de búsqueda entre todos los agentes. Dado que los índices inactivos en Lakebase generan costos de almacenamiento casi nulos, puede aprovisionar miles de corpus aislados dedicados a agentes, usuarios o sesiones específicos. Esto transforma la búsqueda de una instantánea estática a un bucle operativo de lectura y escritura; los datos que un agente escribe en un turno se confirman y se pueden recuperar en el siguiente con garantías transaccionales completas.

Una base única para el bucle del agente

Lakebase elimina la necesidad de conectar almacenes de vectores, clústeres de búsqueda y bases de datos transaccionales independientes. Al consolidar todo el ciclo de vida dentro de un único sistema Postgres, ofrece la escala y el bajo costo del almacenamiento de objetos en la nube por niveles, junto con la ergonomía de lectura y escritura en tiempo real necesaria para los flujos de trabajo de agentes.

Lakebase Search ya está disponible en versión Beta en AWS y Azure. ¿Qué construirán sus agentes?

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original