Apresentando o Lakebase Search: recuperação nativa para agentes integrada ao Lakebase Postgres

Hoje, estamos apresentando o Lakebase Search: recuperação híbrida vetorial e de texto completo integrada ao Lakebase, disponível agora em beta na AWS e no Azure. Desenvolvido com duas extensões nativas do Postgres, lakebase_vector e lakebase_text, ele permite que todo o ciclo do seu agente dependa de um único back-end de dados, um lakebase.

Isso traz escala de última geração, economia incomparável e ergonomia focada em agentes.

Os agentes transformam a busca em um fluxo de trabalho operacional: eles recuperam contexto, raciocinam, agem e lembram. Isso conecta profundamente o caminho de leitura (recuperação) com o caminho de escrita (memória), tornando a recuperação instantânea essencial para acessar insights recém-gerados em tempo real.

Até agora, esse ciclo não tinha um ambiente nativo do Postgres desenvolvido para a escala e a economia que a busca em larga escala exige.

Para agentes, a busca é, na verdade, uma carga de trabalho operacional

Os agentes agora operam 4 vezes mais bancos de dados no Lakebase do que os usuários humanos, e seu requisito principal é totalmente diferente do de um humano. Os mecanismos de busca tradicionais pressupõem um snapshot somente leitura de dados desatualizados. Os agentes, no entanto, tratam a busca como um banco de dados operacional ativo.

Veja um esquema típico de agente: documentos fragmentados e embeddings vivem diretamente ao lado de um log de memória conversacional ativo. Isso cria um ciclo contínuo de leitura/gravação. Os agentes gravam novos aprendizados na memória em um turno e precisam que esses mesmos dados estejam totalmente indexados e pesquisáveis no turno seguinte. Eles não precisam apenas de uma recuperação rápida; eles precisam de busca instantânea nas gravações mais recentes.

A busca é uma carga de trabalho peculiar

A busca é uma carga de trabalho única com duas propriedades definidoras.

Primeiro, você armazena muito mais dados do que realmente consulta, deixando a maior parte deles fria.

Segundo, a busca vetorial causa um inchaço severo de dados. Um arquivo de texto de 1 KB se expande quando vetorizado. Isso ocorre porque o documento é dividido em vários fragmentos, com cada fragmento gerando um embedding de alta dimensão distinto — mesmo antes de contabilizar a sobrecarga do índice.

Quando multiplicadas por milhares de tenants majoritariamente ociosos, as arquiteturas de busca tradicionais falham. Os índices vetoriais que são padrão do setor, como o HNSW, são fundamentalmente limitados pela memória. Como a travessia rápida de grafos depende muito de o índice permanecer residente na RAM, hospedar dados frios de vários tenants é caro.

A busca precisa de um lakebase

No ano passado, apresentamos o Lakebase: uma arquitetura OLTP Postgres serverless onde os dados residem em um armazenamento de objetos em nuvem de baixo custo, mas um cache em camadas (RAM, NVMe local, pageserver) garante que as páginas quentes sejam lidas com latência de disco local.

Percebemos que esta é exatamente a arquitetura de que a busca moderna precisa. Mas havia um detalhe: para realmente viabilizar essa economia sem destruir a velocidade de consulta, você precisa de um layout de índice projetado explicitamente para residir em uma hierarquia de armazenamento em camadas. O Lakebase não tinha isso. Então, nós o desenvolvemos.

Ao combinar uma arquitetura em camadas com um índice em camadas projetado sob medida, alcançamos:

• Escala de última geração sem perda de velocidade: Ao buscar de forma inteligente apenas as páginas necessárias do armazenamento de objetos para um cache local, instâncias menores do Postgres alcançam o mesmo recall e latência sem exigir recursos computacionais massivos.
• Economia incomparável: A cauda fria de vetores fica em um armazenamento de objetos quase gratuito, enquanto o conjunto de trabalho ativo reside no NVMe. Você paga pelo que consulta, não pelo que armazena.

A economia é mais fácil de visualizar em uma tabela. Por terabyte por mês, com base nos preços de tabela da nuvem:

Nosso método de indexação permite que o Lakebase mantenha apenas o conjunto de trabalho ativo na RAM. A maioria fria repousa no armazenamento de objetos, tornando o sistema duas ordens de magnitude mais barato — ao mesmo tempo em que oferece a busca de alto desempenho que sua aplicação realmente exige.

Trazendo índices de busca nativos de lake para o Postgres.

Ao desenvolver o Lakebase Search, focamos em duas propriedades inegociáveis.

Ao desenvolver o Lakebase Search, tínhamos dois requisitos rígidos: ele precisava ser 100% nativo do Postgres (reutilizando tipos padrão de pgvector/tsvector e ferramentas do ecossistema), e a indexação precisava ser desenvolvida do zero para armazenamento de objetos em nuvem em camadas.

Para alcançar isso, estamos lançando hoje duas novas extensões do Postgres em Beta. Ambas compartilham o mesmo objetivo: fornecer relevância de busca de última geração sem forçar você a superdimensionar a RAM.

1. lakebase_vector: compressão de 32x e escala de mais de 1 bilhão.

Mantivemos os tipos de dados e operadores padrão do pgvector, mas alteramos o tipo de índice subjacente. Como os dados permanecem no formato nativo do pgvector, ele mantém a compatibilidade e pode ser exportado para outros sistemas. Ao agrupar e compactar vetores usando RaBitQ (Randomized Binary Quantization), reduzimos o tamanho do índice em 32x, mantendo um alto recall. Um índice de 100 milhões de vetores que antes exigia 300 GB de RAM agora cabe em menos de 10 GB. Essa pegada de memória reduzida permite que um único índice escale para mais de 1 bilhão de vetores. O conjunto de trabalho ativo é armazenado em cache no NVMe local, enquanto a cauda fria reside no armazenamento de objetos.

2. lakebase_text: BM25 real sem o inchaço de memória do GIN.

O Postgres lida com a correspondência exata de palavras-chave por meio de índices GIN, que devem permanecer residentes na RAM para manter o desempenho. Essa arquitetura faz com que os custos de memória escalem linearmente com o tamanho do conjunto de dados.

O lakebase_text substitui o GIN por um índice otimizado para leituras sequenciais a partir do armazenamento de objetos em nuvem. Ele introduz a classificação de relevância BM25 nativa no Postgres sem a pegada de RAM associada.

Como ambas as extensões são executadas no mesmo mecanismo, a busca híbrida é executada em uma única consulta SQL. A similaridade vetorial e a relevância das palavras-chave são combinadas via fusão de classificação recíproca (RRF), permitindo que os resultados sejam unidos e filtrados em relação a tabelas operacionais.

O Postgres está pronto para cargas de trabalho de busca sérias e em larga escala

Realizamos testes de benchmark do Lakebase Search no LAION-100M — 100 milhões de vetores de 768 dimensões, recuperação top-10, em uma única instância. O desempenho da consulta com um cache quente e uma única conexão oferece recall exato do vizinho mais próximo com zero inchaço:

Alcançar essa escala tradicionalmente exige uma arquitetura limitada pela memória. Um índice HNSW padrão do pgvector requer que o grafo de vizinhos e suas páginas de heap de destino permaneçam residentes na RAM para uma travessia de alto desempenho. Com 100 milhões de vetores:

1. pgvector: Exige uma instância de 512 GB (64 CPU). A criação do índice leva cerca de 40 horas. Como a travessia do grafo depende de acesso aleatório não localizado, reinicializações a frio causam pesadas latências de leitura de disco, fazendo com que a primeira consulta leve minutos.
2. lakebase_vector: Executado em uma instância de 192 GB (96 CU / 24 CPU). A criação do índice leva 1,5 hora. Embora a travessia ainda seja por acesso aleatório, o layout do índice agrupa os dados de modo que as buscas aleatórias sejam localizadas dentro de um conjunto de trabalho ativo no cache NVMe, deixando a cauda fria no armazenamento de objetos. A instância escala para zero quando ociosa; a primeira consulta com cache frio leva 1,13 segundo.

Essa arquitetura muda a forma de abordar o custo total de propriedade. A busca legada exige um custo de linha de base fixo, independentemente do volume de consultas, enquanto o Lakebase acompanha o uso real:

O Lakebase Search permite ergonomia focada em agentes

Um único backend para memória e contexto:

Os agentes não deveriam ter que juntar um banco de dados vetorial para contexto e um banco de dados transacional para memória. Ao levar sua lógica de recuperação diretamente para o banco de dados, todo o loop do seu agente é executado em um único backend. Como o Lakebase Search é Postgres — reutilizando totalmente os tipos padrão pgvector e tsvector —, ele se conecta nativamente aos seus MCPs, drivers padrão e conectores existentes. Mais importante ainda, como a pesquisa fica bem ao lado dos seus dados operacionais, você pode executar uma pesquisa híbrida, fazer join com as tabelas da sua aplicação e filtrar por tenant com segurança, tudo em uma única consulta SQL.

Experimentação contínua de pesquisa

Otimizar estratégias de fragmentação (chunking) ou pesos híbridos exige tentativa e erro. Em vez de exportar dados para sistemas em lote (batch) externos para reprocessamento, o Lakebase Search se conecta ao Lakehouse para criar um ciclo de feedback rápido. Você pode ramificar conjuntos de dados de vários terabytes instantaneamente a custo zero, criar índices fora de banda (out-of-band) usando computação paralela e direcionar o feedback do agente de volta ao Lakehouse para avaliação offline.

Um mecanismo de recuperação dedicado por agente

As arquiteturas tradicionais exigem o compartilhamento de um único cluster de pesquisa entre todos os agentes. Como os índices inativos no Lakebase geram custos de armazenamento quase nulos, você pode provisionar milhares de corpora isolados dedicados a agentes, usuários ou sessões específicas. Isso transforma a pesquisa de um snapshot desatualizado em um loop operacional de leitura/gravação; os dados que um agente grava em uma rodada são confirmados (committed) e podem ser recuperados na próxima com garantias transacionais completas.

Uma base única para o loop do agente

O Lakebase elimina a necessidade de interligar repositórios de vetores (vector stores), clusters de pesquisa e bancos de dados transacionais separados. Ao consolidar todo o ciclo de vida dentro de um único sistema Postgres, ele oferece a escala e o baixo custo do armazenamento de objetos em nuvem em camadas, juntamente com a ergonomia de leitura/gravação em tempo real necessária para fluxos de trabalho de agentes.

O Lakebase Search está disponível hoje em Beta na AWS e no Azure. O que seus agentes vão criar?

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original