Databricks traz busca de texto completo e vetorial ao Lakebase Postgres

Databricks em 28 de setembro de 2026, introduziu Lakebase Search, um mecanismo de busca embutido para seu banco de dados Lakebase Postgres entregue por meio de duas extensões: lakebasevetor para busca aproximada de vizinho mais próximo e lakebasetext para busca de texto completo BM25. Ambas as extensões estão geralmente disponíveis na AWS e Azure.

As extensões permitem que desenvolvedores executem buscas semânticas, por palavra‑chave e híbridas diretamente dentro do Postgres ao lado de dados operacionais. A Databricks afirmou que os sistemas OLTP tradicionais não foram projetados para as exigências de busca de agentes de IA, que requerem recuperação de baixa latência e alta precisão e frequentemente executam buscas massivas em paralelo, e que resolver isso até agora significava anexar um mecanismo de busca autônomo ao banco de dados principal por meio de um pipeline ETL. A empresa disse que construiu o Lakebase Search com base no feedback de centenas de clientes beta.

Resultados de Benchmark e a Implantação da Conexiom

A Databricks afirmou que lakebase_vetor oferece o dobro da taxa de transferência do próximo melhor sistema no benchmark VectorDBBench 100M, que utiliza o conjunto de dados LAION, e que é quatro vezes mais barato que um fornecedor de Postgres em nuvem que usa pgvector, antes das economias adicionais do dimensionamento automático. A empresa relatou uma latência P99 de 71 milissegundos com 97 % de recall, o que significa que o mecanismo recuperou com sucesso os verdadeiros vizinhos mais próximos 97 % das vezes, e observou que pgvector e DiskANN foram testados apenas em uma única instância grande.

A Databricks também relatou um resultado de cliente da Conexiom, que executa busca híbrida BM25 em mais de 100 milhões de linhas com metade da pegada computacional de sua configuração anterior de pgvector. A empresa afirmou que os custos de infraestrutura da Conexiom caíram três vezes e a taxa de transferência aumentou cinco vezes em relação ao pgvector.

“Lakebase Search nos oferece um nível totalmente novo de escalabilidade em relação ao pgvector e desbloqueia o BM25 no mesmo banco de dados serverless”, disse Jordan Voves, arquiteto de IA/ML na Conexiom. “Usamos o Lakebase para conectar dados aos nossos agentes em escala.”

As Limitações do Pgvector por Trás do Design

A Databricks afirmou que o pgvector é a extensão mais instalada no Lakebase Postgres e descreveu três pontos problemáticos recorrentes observados em clientes que o utilizam em escala.

O primeiro é o custo, que escala com o volume de dados em vez de com o uso. O pgvector mantém seu índice HNSW na memória do banco de dados e, como a busca HNSW depende de travessia de grafo de acesso aleatório, o desempenho cai de 10 a 50 vezes quando o índice transborda para o disco e as consultas se transformam em cadeias de leituras aleatórias. Um vetor float32 de 768 dimensões ocupa cerca de 3,3 kilobytes de memória quando os links do grafo e a sobrecarga do Postgres são incluídos, de modo que um índice sobre 100 milhões de linhas requer aproximadamente 330 gigabytes de RAM para permanecer residente, provisionado integralmente, independentemente de as consultas o acessarem ou não.

O segundo é a manutenção do índice. Quando uma construção transbordou para o disco, um índice pgvector levou quase 50 horas para ser construído em uma instância padrão de nuvem, afirmou a Databricks, e as gravações sofrem o mesmo gargalo porque inserir um vetor requer travessia de acesso aleatório e modificação de várias camadas do grafo. Como o HNSW não possui reequilíbrio global, recuperar a qualidade da busca significa executar um REINDEX completo, operação que bloqueia a tabela e interrompe as gravações de produção.

O terceiro é que uma única consulta não pode ser paralelizada. Uma consulta pgvector é executada por um único processo backend do Postgres, deixando a varredura do índice HNSW sem paralelismo. Aumentar o recall requer visitar mais nós do grafo, o que adiciona leituras de memória aleatórias e comparações de distância, inflando a latência e reduzindo consultas por segundo, de modo que escalar a taxa de transferência significa adicionar conexões ao banco de dados ou réplicas de leitura.

Como o Lakebase_vector é Construído

O Lakebase Postgres separa armazenamento de computação: dados permanentes residem em armazenamento de objetos em nuvem de baixo custo, enquanto RAM e NVMe local funcionam como caches de curta duração que mantêm o conjunto de trabalho ativo. Sobre essa base, a Databricks combinou duas técnicas.

O agrupamento hierárquico IVF agrupa vetores em clusters armazenados como blocos contíguos. Uma consulta pontua os centróides dos clusters na memória e, em seguida, lê apenas os poucos blocos que parecem promissores como leituras sequenciais grandes, em vez de fazer muitas saltos aleatórios. A quantização binária, usando o método RaBitQ, comprime cada vetor para cerca de um bit por dimensão, aproximadamente 32 vezes menor que float32, de modo que as consultas varrem códigos compactos para criar uma lista curta de candidatos e reordenam apenas essa lista curta contra vetores de precisão total.

Como o design é sem estado, ele escala para zero e, em repouso, os usuários pagam apenas pelo armazenamento. A Databricks relatou um P90 medido de 1,13 segundo para a primeira consulta após o scale‑to‑zero em um conjunto de dados de 100 milhões de vetores, 768 dimensões, e afirmou que 100 milhões de vetores podem ser atendidos em uma única Lakebase Compute Unit.

A construção do índice treina os centróides de cluster uma única vez em uma pequena amostra aleatória; cada vetor é então atribuído ao centróide mais próximo, quantizado e gravado no bloco apropriado como uma operação independente, de modo que o trabalho se distribui por quantos núcleos estiverem disponíveis. A Databricks afirmou que sua arquitetura LTAP transfere a construção de índices do banco de dados primário para motores distribuídos como o Spark, reduzindo o tempo de construção a minutos, e disse que mais recursos virão nessa capacidade. Como os predicados são aplicados durante a varredura do bloco, consultas filtradas evitam a sobrecarga de candidatos e mantêm alta taxa de recall, e uma única consulta é paralelizada entre os núcleos da CPU.

Busca de Texto BM25 e Consultas Híbridas

A Databricks afirmou que a busca padrão tsvector do Postgres carece de contexto de relevância em todo o corpus. O lakebase_text pontua termos usando a frequência inversa de documento global, atribuindo mais peso a termos raros e de alta intenção e menos a palavras de preenchimento comuns. Ele também verifica limites superiores de pontuação ao percorrer o índice, descartando blocos de postings inteiros que não podem influenciar o resultado top‑K, o que a empresa disse tornar a busca mais rápida que o tsvector com índices GIN.

Combinar as duas extensões permite busca híbrida nativa dentro do Postgres: uma única consulta pode aplicar predicados de filtro SQL comuns, juntar tabelas operacionais ao vivo e mesclar a pontuação de vetores semânticos com a relevância de palavras‑chave BM25. A Databricks afirmou que o sistema escala de uma linha para um bilhão de vetores e de uma consulta por segundo para milhares, sem necessidade de reaprovisionamento manual, descrevendo o design como destinado a agentes de IA cujos fluxos de trabalho podem disparar milhares de solicitações de recuperação simultâneas em segundos.

A Databricks posiciona o Lakebase Search para usuários que desejam dados operacionais e de busca consolidados em um único banco de dados, enquanto o Databricks AI Search continua sendo seu mecanismo gerenciado de recuperação pronto para uso. O Lakebase Search está disponível de forma geral na AWS e Azure; usuários existentes do Lakebase podem habilitar as extensões, e novos usuários podem se inscrever no Lakebase.