Databricks apporte la recherche plein texte et vectorielle à Lakebase Postgres

Databricks le 28 septembre 2026, a présenté Lakebase Search, un moteur de recherche intégré pour sa base de données Lakebase Postgres fourni via deux extensions : lakebasevector pour la recherche approximative du voisin le plus proche et lakebasetext pour la recherche plein texte BM25. Les deux extensions sont généralement disponibles sur AWS et Azure.

Les extensions permettent aux développeurs d’exécuter des recherches sémantiques, par mots‑clés et hybrides directement dans Postgres aux côtés des données opérationnelles. Databricks a déclaré que les systèmes OLTP traditionnels n’étaient pas conçus pour les exigences de recherche des agents IA, qui nécessitent une récupération à faible latence et haute précision et exécutent souvent des recherches massivement parallèles, et que résoudre ce problème jusqu’à présent signifiait attacher un moteur de recherche autonome à la base de données principale via un pipeline ETL. L’entreprise a indiqué avoir construit Lakebase Search en s’appuyant sur les retours de centaines de clients bêta.

Résultats du benchmark et déploiement Conexiom

Databricks a indiqué que lakebase_vector offre deux fois le débit du système suivant sur le benchmark VectorDBBench 100M, qui utilise le jeu de données LAION, et qu’il est quatre fois moins cher qu’un fournisseur de Postgres cloud utilisant pgvector, avant les économies supplémentaires liées à l’autoscaling. L’entreprise a rapporté une latence P99 de 71 millisecondes à 97 % de rappel, ce qui signifie que le moteur a récupéré les vrais voisins les plus proches 97 % du temps, et a noté que pgvector et DiskANN n’avaient été testés que sur une seule grande instance.

Databricks a également rapporté un résultat client de Conexiom, qui exécute une recherche hybride BM25 sur plus de 100 millions de lignes avec une empreinte de calcul moitié moindre que son installation pgvector précédente. Les coûts d’infrastructure de Conexiom ont diminué de trois fois et le débit a augmenté de cinq fois par rapport à pgvector, a indiqué l’entreprise.

« Lakebase Search nous offre un tout nouveau niveau de scalabilité par rapport à pgvector, et débloque BM25 dans la même base de données serverless », a déclaré Jordan Voves, architecte IA/ML chez Conexiom. « Nous utilisons Lakebase pour connecter les données à nos agents à grande échelle. »

Les limites de Pgvector derrière la conception

Databricks a indiqué que pgvector est l’extension la plus installée dans Lakebase Postgres, et a décrit trois points de douleur récurrents observés chez les clients l’utilisant à grande échelle.

Le premier est le coût qui augmente avec le volume de données plutôt qu’avec l’utilisation. pgvector conserve son index HNSW en mémoire de la base de données, et comme la recherche HNSW repose sur un parcours aléatoire du graphe, les performances chutent d’un facteur de 10 à 50 dès que l’index déborde sur le disque et que les requêtes se transforment en chaînes de lectures aléatoires. Un vecteur float32 de 768 dimensions occupe environ 3,3 ko de mémoire une fois les liens du graphe et la surcharge de Postgres inclus, de sorte qu’un index sur 100 millions de lignes nécessite approximativement 330 gigaoctets de RAM pour rester en mémoire, provisionnés en totalité que les requêtes y accèdent ou non.

Le deuxième est la maintenance de l’index. Lorsqu’une construction déborde sur le disque, un index pgvector a mis près de 50 heures à se construire sur une instance cloud standard, selon Databricks, et les écritures subissent le même goulot d’étranglement car l’insertion d’un vecteur nécessite un parcours aléatoire et la modification de plusieurs couches du graphe. Puisque HNSW ne dispose d’aucun rééquilibrage global, restaurer la qualité de recherche implique d’exécuter un REINDEX complet, une opération qui verrouille la table et interrompt les écritures en production.

Le troisième est qu’une seule requête ne peut pas être parallélisée. Une requête pgvector est exécutée par un seul processus backend de Postgres, laissant le scan de l’index HNSW sans aucune parallélisation. Améliorer le rappel nécessite de visiter davantage de nœuds du graphe, ce qui ajoute des lectures mémoire aléatoires et des comparaisons de distances, augmentant la latence et réduisant le nombre de requêtes par seconde ; ainsi, augmenter le débit implique d’ajouter des connexions à la base de données ou des réplicas de lecture.

Comment Lakebase_vector est construit

Lakebase Postgres sépare le stockage du calcul : les données permanentes résident dans un stockage d’objets cloud à faible coût, tandis que la RAM et le NVMe local servent de caches temporaires contenant l’ensemble de travail actif. Sur cette base, Databricks a combiné deux techniques.

Le regroupement hiérarchique IVF regroupe les vecteurs en clusters stockés sous forme de blocs contigus. Une requête évalue les centroïdes des clusters en mémoire, puis ne lit que le petit nombre de blocs qui semblent prometteurs, sous forme de lectures séquentielles importantes plutôt que de nombreux sauts aléatoires. La quantification binaire, utilisant la méthode RaBitQ, compresse chaque vecteur à environ un bit par dimension, soit environ 32 fois plus petit que le float32, de sorte que les requêtes parcourent des codes compacts pour présélectionner des candidats et ne reclassent que cette présélection contre les vecteurs en pleine précision.

Comme la conception est sans état, elle peut passer à zéro, et au repos les utilisateurs ne paient que pour le stockage. Databricks a rapporté un P90 mesuré de 1,13 seconde pour la première requête après mise à zéro sur un jeu de données de 100 millions de vecteurs de 768 dimensions, et a indiqué que 100 millions de vecteurs peuvent être servis sur une seule Lakebase Compute Unit.

La construction d’index entraîne les centroïdes de cluster une seule fois sur un petit échantillon aléatoire ; chaque vecteur est ensuite attribué à son centroïde le plus proche, quantifié, et écrit dans le bloc approprié comme une opération indépendante, de sorte que le travail se répartit sur le nombre de cœurs disponibles. Databricks a indiqué que son architecture LTAP décharge la construction d’index de la base de données principale vers des moteurs distribués tels que Spark, réduisant les temps de construction à quelques minutes, et a ajouté que d’autres améliorations sont à venir pour cette capacité. Parce que les prédicats sont appliqués pendant le scan du bloc lui‑même, les requêtes filtrées évitent la sur‑récupération de candidats et maintiennent un rappel élevé, et une requête unique se parallélise sur les cœurs CPU.

Recherche de texte BM25 et requêtes hybrides

Databricks a indiqué que la recherche tsvector standard de Postgres ne prend pas en compte le contexte de pertinence à l’échelle du corpus. lakebase_text attribue des scores aux termes en utilisant la fréquence inverse de document globale, accordant plus de poids aux termes rares et à forte intention et moins aux mots de remplissage courants. Il vérifie également les limites supérieures du score lors du parcours de l’index, en éliminant les blocs de postings entiers qui ne peuvent pas influencer le résultat top‑K, ce que l’entreprise affirme rendre la recherche plus rapide que tsvector avec des index GIN.

Combiner les deux extensions permet une recherche hybride native dans Postgres : une requête unique peut appliquer des prédicats de filtrage SQL ordinaires, joindre des tables opérationnelles en temps réel, et fusionner le scoring sémantique des vecteurs avec la pertinence des mots‑clés BM25. Databricks a déclaré que le système passe d’une ligne à un milliard de vecteurs et d’une requête par seconde à des milliers sans re‑provisionnement manuel, décrivant la conception comme destinée aux agents IA dont les flux de travail peuvent déclencher des milliers de requêtes de récupération concurrentes en quelques secondes.

Databricks positionne Lakebase Search pour les utilisateurs qui souhaitent consolider les données opérationnelles et de recherche dans une seule base de données, tandis que Databricks AI Search reste son moteur géré pour la récupération prête à l’emploi. Lakebase Search est généralement disponible sur AWS et Azure ; les utilisateurs existants de Lakebase peuvent activer les extensions, et les nouveaux utilisateurs peuvent s’inscrire à Lakebase.