Databricks Lakebase Search remet en cause les piles de recherche séparées

Databricks a rendu Databricks Lakebase Search généralement disponible sur AWS et Azure, en intégrant deux moteurs de recherche à son service Postgres géré. La version du 28 septembre prend en charge la récupération vectorielle et le classement de mots-clés BM25 sans nécessiter de base de données de recherche distincte. Elle remet en cause une architecture d’IA familière : Postgres héberge les enregistrements opérationnels, tandis qu’un autre système indexe des copies pour la récupération.

L’entreprise affirme que sa nouvelle extension vectorielle peut rechercher 100 millions de vecteurs avec un rappel de 97 % et une latence P99 de 71 millisecondes. Elle revendique également un débit deux fois supérieur à celui du système suivant dans son benchmark et un coût quatre fois inférieur à celui de Postgres cloud exécutant pgvector. Ces résultats sont importants, mais Databricks a réalisé les tests et n’a pas publié de validation indépendante complète.

L’enjeu dépasse la simple présence d’un index vectoriel supplémentaire. Databricks Lakebase Search cherche à faire en sorte que Postgres opérationnel prenne en charge la récupération sémantique, par mots-clés et hybride à l’échelle des agents. Si cette architecture fonctionne sous de véritables charges de production, certaines équipes pourront supprimer un service de recherche et les pipelines de données qui l’entourent. La pression s’exerce à la fois sur les déploiements pgvector et sur les systèmes de recherche dédiés qui justifiaient leur complexité par une meilleure capacité de mise à l’échelle.

Databricks Lakebase Search intègre la récupération dans Postgres

Cette version transforme la recherche, d’un service connecté, en une capacité gérée de la base de données opérationnelle.

L’annonce technique présente deux extensions Postgres. lakebase_vector gère la recherche approximative des plus proches voisins, qui identifie les vecteurs proches d’une requête sans comparer tous les enregistrements possibles. lakebase_text fournit BM25, une méthode de classement qui pondère la fréquence des termes, la longueur des documents et la rareté des termes au sein d’une collection.

Les deux extensions sont généralement disponibles pour les projets Lakebase sur AWS et Azure. Les développeurs peuvent installer l’une ou l’autre extension, ou les combiner pour une récupération hybride. Cette combinaison compte, car la recherche vectorielle et la recherche par mots-clés répondent à différents modes de défaillance.

La recherche vectorielle compare des embeddings, des représentations numériques du sens. Elle peut faire correspondre une requête telle que « voiture de sport rapide » à des enregistrements mentionnant un modèle automobile, même lorsque ces mots exacts sont absents. La recherche par mots-clés reste plus efficace pour les identifiants, les noms, les codes d’erreur, les références produit et d’autres termes dont la forme littérale est porteuse de sens.

La recherche hybride exécute les deux méthodes et fusionne leurs classements. Un agent de support IA peut utiliser la similarité sémantique pour trouver des incidents liés sur le plan conceptuel tout en préservant une correspondance exacte pour un code d’erreur spécifique. Un agent e-commerce peut interpréter l’intention d’un acheteur sans perdre un numéro de modèle demandé.

Ces opérations s’exécutent à côté des enregistrements transactionnels, plutôt que sur une copie synchronisée séparément. Un développeur peut filtrer la récupération à l’aide de champs actuels tels que le locataire, l’état des stocks, les droits d’accès ou l’état du flux de travail. Databricks indique que lakebase_vector applique les filtres lors de l’analyse des blocs d’index, réduisant le besoin de récupérer un large ensemble de candidats puis d’écarter les lignes non autorisées ou non pertinentes.

Cette conception cible un problème persistant des systèmes de récupération. La version la plus récente d’un enregistrement réside souvent dans la base de données de l’application, tandis que sa version consultable arrive plus tard via un pipeline d’extraction. Même un court délai peut exposer un agent à des documents supprimés, à des autorisations obsolètes ou à des stocks qui n’existent plus.

Maintenir la récupération à proximité des données opérationnelles réduit cette fenêtre de synchronisation. Cela peut également réduire le nombre de systèmes que les ingénieurs doivent surveiller, sécuriser et réparer. Ce changement est particulièrement pertinent pour les équipes qui construisent une base de connaissances consultable, où les contrôles d’accès et les modifications de documents doivent rester alignés sur les résultats de recherche.

Lakebase Search n’élimine pas toutes les étapes de déplacement des données. Les embeddings doivent toujours être générés, le contenu source peut provenir de l’extérieur de Postgres et les tables lakehouse nécessitent une synchronisation avant d’être utilisées. La différence est que les applications peuvent interroger les index résultants via des types et opérateurs Postgres familiers.

Databricks relie également cette fonctionnalité à sa plateforme lakehouse plus large. Sa documentation produit explique comment les tables Unity Catalog peuvent être synchronisées dans Lakebase. Au cours de ce processus, une colonne d’embeddings peut devenir un vecteur Postgres, tandis que le texte source peut devenir un tsvector, la représentation optimisée de PostgreSQL pour la récupération de texte.

Le changement immédiat est donc concret. Lakebase propose désormais des index gérés natifs pour la recherche fondée sur le sens et sur les termes exacts, et les applications peuvent les interroger aux côtés des champs opérationnels. La tension commence avec ce que cette consolidation remplace.

Les agents IA mettent sous pression le pipeline de recherche séparé

Les charges de travail des agents rendent les erreurs de synchronisation et l’infrastructure inactive plus difficiles à justifier.

Une architecture de recherche traditionnelle contient généralement au moins deux magasins de données. Postgres enregistre les transactions et l’état de l’application. Un moteur de recherche ou une base de données vectorielle reçoit des copies transformées via un pipeline d’extraction, de transformation et de chargement.

Cette séparation peut bien fonctionner à grande échelle, mais elle crée des obligations opérationnelles. Les équipes doivent détecter les mises à jour échouées, rejouer les enregistrements manquants, coordonner les changements de schéma, préserver la sémantique de suppression et reproduire les autorisations de la base de données dans un autre système. Elles doivent également prévoir la reconstruction des index sans interrompre l’application.

Les agents IA amplifient ces obligations, car la récupération devient partie intégrante d’une boucle de décision. Une page de recherche classique peut tolérer un résultat imparfait pendant qu’un utilisateur examine les alternatives. Un agent peut agir immédiatement après avoir récupéré un enregistrement, ce qui rend la fraîcheur et l’autorisation plus déterminantes.

Un agent de gestion de comptes illustre ce problème. Il peut rechercher sémantiquement des notes de réunion, faire correspondre un identifiant de contrat exact et filtrer les résultats selon les autorisations actuelles de l’utilisateur. Si ces trois signaux résident dans des systèmes différents, l’application doit les réconcilier avant que le modèle puisse répondre en toute sécurité.

Le même problème apparaît dans le commerce. Un agent d’achat peut interpréter une demande ambiguë grâce aux embeddings, mais la disponibilité et les restrictions régionales proviennent de colonnes opérationnelles évoluant rapidement. Rechercher une copie obsolète peut produire une réponse convaincante pour un article indisponible.

Les usages par à-coups créent une autre source de pression. La recherche d’entreprise destinée aux humains suit souvent des heures de travail prévisibles. Les agents peuvent générer de nombreux appels de récupération parallèles lorsqu’ils planifient, vérifient et révisent une tâche. Une seule demande utilisateur peut déclencher plusieurs recherches plutôt qu’une seule.

Databricks a conçu Lakebase Search autour de cette demande irrégulière. Lakebase sépare le stockage durable du calcul, en conservant les données dans le stockage objet tout en utilisant la mémoire et les NVMe locaux comme caches. Le calcul de recherche peut être suspendu lorsqu’il est inactif et reprendre lorsqu’une autre requête arrive.

L’entreprise rapporte une latence P90 de 1,13 seconde pour la première requête après une mise à l’échelle à zéro sur un index contenant 100 millions de vecteurs de 768 dimensions. Elle indique également que la même collection peut être servie avec une Lakebase Compute Unit. Il s’agit de mesures de l’entreprise, et non d’attentes universelles, mais elles montrent le modèle d’exploitation visé.

Une requête à froid d’une seconde ne conviendra pas à toutes les applications interactives. Elle peut toutefois être acceptable pour un agent interne peu utilisé si elle évite de faire fonctionner continuellement un important cluster de recherche. Les équipes peuvent maintenir le calcul actif lorsque la latence est importante et permettre aux environnements plus calmes de se suspendre.

La construction de l’index s’éloigne également du chemin principal des transactions. Databricks indique pouvoir entraîner des centroïdes à partir d’un échantillon, distribuer l’affectation et la quantification des vecteurs, puis écrire des blocs d’index indépendants. Le déport futur vers des moteurs distribués tels que Spark fait partie de l’orientation de l’entreprise, bien que l’annonce invite à attendre cette capacité plus large.

Cela compte, car les grandes constructions d’index entrent en concurrence avec les charges transactionnelles lorsqu’elles consomment les mêmes ressources de processeur, de mémoire et de stockage. Éloigner ce travail de la base de données principale peut réduire les interférences. Cela modifie également le modèle de coût : au lieu de maintenir un serveur d’index provisionné en permanence, il s’agit de payer pour le calcul de récupération actif et le stockage durable.

La cible de cette pression n’est pas chaque déploiement de recherche dédié. Les grandes équipes de recherche ont souvent besoin d’analyseurs spécialisés, de pipelines de classement personnalisés, d’une observabilité avancée ou de fonctionnalités développées pendant des années. Lakebase exerce plutôt une pression sur l’architecture courante où un second système existe principalement parce que la recherche Postgres ne pouvait plus évoluer confortablement.

Cette distinction maintient l’annonce dans une perspective réaliste. Databricks ne soutient pas qu’une seule base de données devrait exécuter toutes les charges de travail de recherche. L’entreprise affirme qu’un plus grand nombre d’applications d’IA peuvent reporter, simplifier ou éviter cette séparation.

La recherche vectorielle Lakebase vise le modèle mémoire de pgvector

La compétition principale oppose Lakebase Search, adossé au stockage, aux index pgvector gourmands en mémoire à grande échelle.

Pgvector a fait de Postgres un point de départ pratique pour la récupération sémantique. Il ajoute des types vectoriels, des opérateurs de distance, une recherche exacte et des index approximatifs sans contraindre les développeurs à adopter une interface de base de données inconnue. Il reste open source et largement disponible parmi les services Postgres hébergés.

Ses options approximatives standard comprennent HNSW et IVFFlat. HNSW crée un graphe multicouche reliant des vecteurs proches. Il offre un bon équilibre entre vitesse et rappel, mais la construction du graphe prend du temps et l’index consomme beaucoup de mémoire. IVFFlat regroupe les vecteurs en listes et recherche les groupes les plus prometteurs, réduisant les coûts de mémoire et de construction tout en offrant généralement des performances de requête inférieures.

Les propres recommandations de pgvector documentent ces compromis. Elles notent que les index HNSW se construisent beaucoup plus rapidement lorsque le graphe tient dans maintenance_work_mem. Elles avertissent également qu’augmenter le nombre de candidats de recherche améliore le rappel au prix de la vitesse de requête.

Databricks affirme que ces contraintes deviennent plus difficiles à gérer lorsqu’un graphe HNSW dépasse la mémoire d’une machine. Récupérer une chaîne de nœuds de graphe depuis un stockage objet distant peut produire de nombreuses petites lectures aléatoires. Une conception optimisée pour la mémoire résidente devient moins efficace lorsque l’ensemble de travail est froid.

La recherche vectorielle Lakebase utilise un regroupement hiérarchique de fichiers inversés pour modifier ce schéma d’accès. Les vecteurs sont regroupés dans des blocs contigus. Une requête évalue d’abord les centroïdes de cluster, puis lit les blocs associés aux clusters les plus prometteurs.

L’extension associe cette disposition à la quantification binaire RaBitQ, qui compresse chaque vecteur à environ un bit par dimension pour l’évaluation initiale des candidats. Databricks décrit cette représentation comme environ 32 fois plus petite qu’un vecteur standard à virgule flottante de 32 bits. Le système réordonne ensuite un ensemble limité de candidats à l’aide de vecteurs en pleine précision.

Ce mécanisme rend l’index plus adapté à la fois au stockage objet et au cache local. Une requête à froid lit plusieurs blocs pertinents au lieu de suivre des centaines de liens de graphe. Une requête à chaud peut analyser des codes binaires compacts tout en conservant une empreinte active plus réduite en mémoire.

Databricks affirme qu’un seul index lakebase_ann peut contenir plus d’un milliard de vecteurs. Sa documentation indique également que la construction des index est 50 à 100 fois plus rapide que HNSW. Ces chiffres décrivent l’implémentation de l’entreprise et ne doivent pas être appliqués automatiquement à tous les schémas, modèles d’embeddings ou distributions de filtres.

Le benchmark mis en avant a utilisé 100 millions de vecteurs issus du jeu de données LAION. Selon Databricks, Lakebase a offert un débit deux fois supérieur à celui du meilleur système concurrent testé. L’entreprise a rapporté un rappel de 97 % à 71 millisecondes de P99, ce qui signifie que 99 % des requêtes mesurées se sont terminées dans cette latence tout en retrouvant les vrais voisins au taux indiqué.

Le benchmark a également servi de base à l’affirmation d’un coût quatre fois inférieur par rapport à un fournisseur cloud Postgres non nommé utilisant pgvector. Databricks précise que pgvector et DiskANN ont été testés sur de grandes instances uniques. Cette réserve limite la comparaison, car l’architecture, la configuration, le matériel, la concurrence et les hypothèses tarifaires peuvent modifier sensiblement les résultats.

Un benchmark peut montrer qu’une approche mérite d’être évaluée sans pour autant trancher la décision d’achat. Databricks n’a pas établi que toutes les charges de travail pgvector devraient migrer. Les petits index peuvent tenir confortablement en mémoire, et une installation pgvector existante peut être peu coûteuse, portable et simple à exploiter.

Pgvector prend également en charge la quantification binaire, l’indexation en demi-précision, les analyses itératives, le partitionnement et un effort de recherche configurable. Les équipes disposant de déploiements optimisés ont davantage d’options que ne le suggère un simple graphique de référence. L’extension open source fonctionne dans de nombreux environnements Postgres, tandis que Lakebase Search fait partie d’un service Databricks managé.

La compatibilité réduit toutefois le coût de migration. Databricks indique que lakebase_vector utilise les types de vecteurs, opérateurs de distance et syntaxe de requête de pgvector. Une application peut conserver un SQL familier tout en créant un index lakebase_ann à la place d’un index HNSW ou IVFFlat.

Il s’agit d’un choix concurrentiel délibéré. Databricks ne demande pas aux développeurs d’abandonner le modèle de programmation pgvector. L’entreprise propose un moteur de stockage et d’indexation différent sous une interface largement identique.

Les témoignages clients apportent un signal concret. Conexiom a déclaré à Databricks qu’elle exécutait une recherche hybride BM25 sur plus de 100 millions de lignes avec la moitié de l’empreinte de calcul de son ancienne configuration pgvector. Ce témoignage est utile car il décrit une charge de travail opérationnelle, mais il reste une déclaration de client sélectionnée par le fournisseur, sans méthodologie publiée de manière indépendante.

L’argument en faveur de la recherche vectorielle Lakebase est le plus solide lorsque la collection est volumineuse, que la demande de requêtes est irrégulière et que les filtres opérationnels comptent. Il devient moins convaincant lorsque les équipes privilégient la portabilité de l’infrastructure, ont une demande prévisible et permanente, ou atteignent déjà leurs objectifs de latence avec pgvector.

BM25 natif change la donne de la recherche plein texte

La partie la plus discrète de la sortie pourrait être plus importante que le benchmark vectoriel.

De nombreux produits de recherche IA accordent trop d’importance aux embeddings. L’appariement sémantique aide lorsque les utilisateurs et les documents expriment la même idée avec des mots différents. Il est moins fiable lorsqu’une requête contient un identifiant exact qu’un modèle d’embeddings considère comme faible ou inconnu.

Prenons un agent recherchant « CVE-2026-1234 », un numéro de compte client ou le nom d’un composant précis. La recherche par similarité peut renvoyer des enregistrements liés sur le plan conceptuel tout en négligeant l’importance de la chaîne exacte. Le classement par mots-clés fournit un signal de récupération distinct qui préserve les correspondances littérales.

L’extension lakebase_text de Lakebase ajoute un index lakebase_bm25 compatible avec les valeurs PostgreSQL tsvector et les opérateurs de requête textuelle. BM25 intègre la fréquence des termes à l’échelle de la collection et la longueur des documents, aidant les termes rares à contribuer davantage que les termes courants.

PostgreSQL offre déjà des fonctions substantielles de recherche plein texte. Il peut analyser les documents, normaliser les mots, supprimer les mots vides, construire des index GIN et classer les résultats avec ts_rank ou ts_rank_cd. La documentation officielle sur le classement indique que ses fonctions de classement intégrées utilisent la fréquence lexicale, la proximité et des informations structurelles.

Ces fonctions n’utilisent pas les statistiques globales de la collection de la même manière que BM25. Cette différence est importante lorsqu’un produit nécessite une pertinence de type moteur de recherche plutôt qu’une simple correspondance. Historiquement, les équipes ont ajouté une logique de classement personnalisée ou déplacé le texte vers un moteur dédié.

Databricks indique que lakebase_text utilise Block-Max WAND pour la récupération top-K. Cet algorithme ignore les régions qui ne peuvent pas produire un résultat compétitif face aux scores les plus élevés actuels. Au lieu d’évaluer intégralement chaque document correspondant, le moteur concentre son travail sur les candidats susceptibles d’entrer dans l’ensemble de résultats demandé.

Cette approche complète la récupération vectorielle. Une requête de support pourrait être exécutée sur lakebase_bm25 pour le texte d’erreur exact et sur lakebase_ann pour des descriptions d’incidents sémantiquement similaires. La fusion réciproque des rangs peut ensuite combiner les deux listes ordonnées sans supposer que leurs scores bruts partagent la même échelle.

C’est ici que Databricks Lakebase Search devient plus qu’un index vectoriel plus rapide. Il propose une pile de recherche réunissant deux modèles de récupération distincts dans la même base de données. La ligne opérationnelle, l’embedding, la représentation textuelle et les attributs de filtrage peuvent rester ensemble.

Cette consolidation affecte autant la sécurité que la commodité. Une application peut exprimer les limites de locataire et les contrôles d’autorisation sous forme de prédicats SQL parallèlement à la récupération. Les ingénieurs doivent toujours vérifier que chaque chemin d’index applique correctement les filtres, mais ils évitent de recréer tout un modèle d’autorisation dans un service distinct.

Elle simplifie aussi le comportement d’écriture. Un enregistrement nouvellement inséré peut devenir consultable sans attendre qu’une deuxième base de données accuse réception d’un événement. Les mises à jour et suppressions restent dans un environnement transactionnel familier, même si le délai de maintenance des index et les sources lakehouse synchronisées doivent encore être mesurés.

Les moteurs dédiés conservent des avantages importants. Elasticsearch et les systèmes similaires prennent en charge une analyse linguistique étendue, un scoring personnalisé, des agrégations, la mise en évidence, des outils de requête et des contrôles opérationnels conçus spécifiquement pour la recherche. La prise en charge de BM25 par Lakebase n’efface pas ces différences.

La comparaison pertinente est donc architecturale. Si une application a besoin de récupération sémantique, de classement par termes exacts, de filtres opérationnels actualisés et de SQL ordinaire, Lakebase peut couvrir une plus grande partie de cette charge de travail en un seul endroit. Si la recherche est elle-même le produit, des capacités spécialisées peuvent toujours justifier un système distinct.

Le benchmark laisse des questions de production sans réponse

Databricks a présenté un mécanisme attrayant, mais les acheteurs ont encore besoin de preuves propres à leur charge de travail.

La plus grande incertitude concerne l’indépendance du benchmark. Databricks a sélectionné les systèmes, configurations, jeu de données, tailles d’instances et hypothèses de coût derrière sa comparaison publiée. L’entreprise identifie VectorDBBench et le jeu de données LAION de 100 millions d’éléments, mais l’annonce ne fournit pas assez de détails pour reproduire chaque résultat à partir du seul article.

Le rappel et la latence interagissent également. La récupération approximative évite intentionnellement la comparaison exhaustive, de sorte que les ingénieurs règlent le nombre de clusters ou de candidats examinés par une requête. Un rappel plus élevé exige souvent davantage de travail. Un seul point de performance ne peut pas décrire toute la courbe à différents niveaux de rappel cible.

Le filtrage peut encore modifier cette courbe. Les requêtes métier réelles peuvent restreindre les résultats par locataire, zone géographique, période, état des stocks ou autorisation. Un benchmark uniformément distribué ne représente pas nécessairement des filtres de production très sélectifs ou inégaux.

La forme des données compte aussi. Les embeddings d’images de LAION diffèrent des embeddings de documents d’entreprise, des catalogues de produits, du code source ou des dossiers clients. Les dimensions varient, des doublons apparaissent, les mises à jour arrivent de manière inégale et certains locataires dominent le trafic. Chaque facteur peut affecter le comportement du cache et la qualité de l’index.

Les performances de démarrage à froid méritent une interprétation prudente. Le P90 rapporté de 1,13 seconde s’applique à une configuration précise de 100 millions de vecteurs et 768 dimensions. Les applications ayant des objectifs interactifs stricts peuvent nécessiter une capacité de calcul active plutôt qu’une mise à l’échelle à zéro. Les équipes devraient tester à la fois la première requête et la rafale qui suit.

Les contraintes opérationnelles exigent également de l’attention. Selon la documentation, l’activation de Lakebase Search redémarre chaque ressource de calcul d’un projet, interrompt les connexions actives et ne peut pas être annulée. Cette activation constitue donc un changement d’infrastructure planifié plutôt qu’un simple basculement d’extension sans conséquence.

La portabilité représente un autre compromis. Lakebase présente des types Postgres standard et une syntaxe pgvector familière, mais ses nouvelles méthodes d’accès aux index sont des capacités managées propriétaires. Une équipe peut conserver une grande partie de son SQL applicatif tout en devenant dépendante de Databricks pour le comportement des index, la montée en charge et la tarification.

La même préoccupation s’applique à BM25. Les colonnes tsvector standard restent des objets Postgres reconnaissables, mais l’index lakebase_bm25 et ses caractéristiques d’exécution sont spécifiques à Lakebase. Un départ pourrait nécessiter de reconstruire les index et de retester la qualité du classement ailleurs.

Les affirmations de coût nécessitent des mesures directes. La suspension serverless peut réduire les dépenses pour un usage irrégulier, mais une forte concurrence soutenue peut favoriser un modèle différent. La génération d’embeddings, les tables synchronisées, le stockage, les transferts de données et les services Databricks environnants contribuent au coût total de l’architecture.

Les équipes devraient donc évaluer Lakebase Search avec des requêtes représentatives plutôt qu’avec un classement générique. Un corpus de test utile inclut les enregistrements actuels, les enregistrements supprimés, les documents à accès contrôlé, les identifiants rares, les requêtes ambiguës en langage naturel et les filtres les plus susceptibles de réduire le rappel.

Elles devraient également comparer les résultats opérationnels. Mesurez la fraîcheur des données, la récupération après incident, l’impact de la construction des index, la cohérence des autorisations et le temps du personnel nécessaire à la gestion des pipelines. Supprimer un service externe peut être précieux même lorsque la latence brute des requêtes évolue peu.

Aucune de ces questions n’invalide la sortie. Elles définissent ce que doit signifier « état de l’art » en dehors d’un benchmark fournisseur. L’architecture repose sur une justification technique crédible, mais les preuves en production doivent montrer que ses avantages résistent à la distribution de données et à la charge de travail de chaque acheteur.

Ce qu’il faut surveiller après la disponibilité générale de Lakebase Search

Trois signaux détermineront si Lakebase Search devient une fonctionnalité Postgres par défaut ou reste une option spécifique à Databricks.

Le premier signal est la performance reproductible. Des tests indépendants devraient comparer Lakebase à pgvector optimisé, à des services basés sur DiskANN et à des moteurs de recherche dédiés pour plusieurs objectifs de rappel. Ils devraient publier les spécifications des instances, la concurrence, la sélectivité des filtres, l’état du cache, le temps de construction des index et l’ensemble des hypothèses de coût.

Des résultats proches des affirmations de Databricks renforceraient l’idée que les index en clusters adossés au stockage conviennent mieux aux grandes collections serverless que les graphes orientés mémoire. Un écart important affaiblirait le récit de performance, même si la consolidation continue d’offrir des avantages opérationnels.

Le deuxième signal est l’adoption par des équipes remplaçant des architectures à deux systèmes. Conexiom fournit un premier exemple, mais le marché a besoin de davantage de témoignages décrivant l’échelle de production, la fréquence des mises à jour, le volume de requêtes et les modèles d’autorisation. Les récits les plus convaincants documenteront un cluster de recherche ou un pipeline ETL supprimé, et non une simple démonstration réussie.

L’adoption révélera également si la syntaxe Postgres familière réduit les frictions de migration. Si les équipes peuvent modifier les définitions d’index tout en conservant leur modèle de données et leurs requêtes, Lakebase Search dispose d’une voie concrète vers les applications existantes. Si les migrations exigent d’importants changements de classement, l’affirmation de compatibilité aura moins de poids.

Le troisième signal concerne la réponse concurrentielle. Pgvector continue d’ajouter des options de quantification, de filtrage et d’analyses itératives. Les fournisseurs de Postgres managé peuvent améliorer leur architecture de stockage ou introduire leurs propres extensions de recherche. Les fournisseurs de recherche spécialisés peuvent mettre en avant des contrôles de classement éprouvés, une flexibilité de déploiement et des fonctionnalités de récupération hybride.

Databricks a commencé à positionner Lakebase comme un Postgres managé pour les applications d’IA dans son annonce de lancement de 2025. Cette version rend ce positionnement plus concret. Les transactions seules ne rendent pas une base de données prête pour les agents si chaque requête de récupération sérieuse doit encore quitter le système.

La conclusion immédiate est plus ciblée et plus utile. Databricks Lakebase Search offre aux développeurs un emplacement managé unique pour les enregistrements opérationnels, la similarité vectorielle, le classement BM25 et le filtrage SQL. Son index vectoriel quantifié et en clusters répond directement au modèle de mémoire qui limite les grands déploiements pgvector.

La prochaine décision revient aux équipes d’ingénierie. Créez un test de récupération représentatif, incluez du trafic à froid et à chaud, appliquez de véritables filtres d’autorisation et comparez l’ensemble de la charge opérationnelle. Si Lakebase préserve la pertinence tout en supprimant l’infrastructure de synchronisation, la simplification architecturale comptera davantage que n’importe quelle barre de benchmark isolée.