LanceDB a chargé 100 000 embeddings OpenAI 22 fois plus vite que pgvector, tandis que pgvector a répondu à la même charge de travail provenant de huit clients simultanés 1,8 fois plus rapidement. L'écart en matière de latence monothread et d'efficacité de stockage a également penché en faveur de LanceDB, offrant aux développeurs un moyen fondé sur les données de choisir un magasin de vecteurs.

Pourquoi un benchmark est important aujourd'hui

La recherche vectorielle est passée des laboratoires de recherche aux services de production tels que les moteurs de recommandation et la génération augmentée par récupération (RAG). La plupart des équipes utilisent déjà PostgreSQL, donc l'extension pgvector promet une recherche de similarité sans nouvelle infrastructure. Les magasins dédiés comme LanceDB revendiquent toutefois une latence plus faible et un stockage moins coûteux. Les équipes doivent choisir entre « l'ajouter à ce que nous avons déjà » et « exécuter un moteur conçu à cet effet », une décision qui impacte le coût et les performances à mesure que les ensembles de données s'agrandissent et que le taux de requêtes augmente.

Comment le test a été configuré

Les deux systèmes ont indexé les mêmes 100 000 vecteurs, chacun ayant 1536 dimensions, générés par le modèle d'embedding d'OpenAI. Nous avons mesuré la vitesse d'ingestion, l'utilisation du disque, la latence de requête monothread et le débit avec huit clients simultanés.

Résultats comparatifs

  • Vitesse d'ingestion – LanceDB a enregistré un avantage de 22×.
  • Empreinte disque – LanceDB a stocké les vecteurs dans environ un tiers de l'espace utilisé par pgvector.
  • Latence monothread – Les requêtes ont été environ deux fois plus rapides sur LanceDB.
  • Passage à l'échelle de la concurrence – Avec huit clients parallèles, pgvector a délivré un débit 1,8× supérieur à celui de LanceDB.

Racines architecturales des différences

LanceDB est une bibliothèque embarquée qui s'exécute à l'intérieur du processus Python qui héberge l'application. Toutes les opérations restent dans le processus, de sorte que les données ne traversent jamais de limite réseau et que l'index se met à jour avec un overhead minimal. Cette conception excelle pour les charges de travail monotâche, mais atteint un plafond lorsque plusieurs threads Python se disputent le Global Interpreter Lock (GIL), ce qui bloque l'exécution parallèle réelle du bytecode Python.

pgvector étend PostgreSQL côté serveur. Chaque connexion client lance un processus serveur distinct, contournant ainsi entièrement le GIL. Le planificateur PostgreSQL décide de la manière de satisfaire une recherche de similarité, et le serveur peut lancer de nombreux processus pour servir des requêtes simultanées. Cette isolation explique la meilleure mise à l'échelle sous charge.

Particularités du filtrage et de la planification de requêtes

Les pipelines RAG en conditions réelles combinent souvent la similarité vectorielle avec des filtres traditionnels (par exemple, WHERE user_id = 42). LanceDB applique un pré-filtrage qui se comporte de manière prévisible lors des exécutions. pgvector s'appuie sur le planificateur de requêtes de PostgreSQL, qui peut choisir un scan d'index rapide ou se rabattre sur un scan exact plus lent en fonction des statistiques. L'exécution de ANALYZE après le chargement massif d'une table pgvector actualise ces statistiques ; sans cela, le rappel (recall) peut chuter presque à zéro, ce qui casse pratiquement la recherche.

Quand chaque option est pertinente

Choisissez pgvector si

  • Votre stack inclut déjà PostgreSQL et vous souhaitez éviter d'ajouter un autre service.
  • Vous prévoyez de nombreux utilisateurs simultanés ou de nombreux appels d'API.
  • Les garanties ACID et les outils DBA familiers sont importants.

Choisissez LanceDB si

  • Votre flux de travail est un pipeline de ML qui ingère fréquemment de nouveaux embeddings.
  • Vous avez besoin du chemin d'écriture le plus rapide et d'une faible latence pour des agents à requête unique (par exemple, des chatbots).
  • Le coût du disque est une préoccupation et vous pouvez tolérer le plafond de performance monothread.

En résumé : Si la vitesse d'ingestion brute, le stockage minimal et la latence de requête unique sont les critères les plus importants, LanceDB l'emporte. Si vous devez servir de nombreux utilisateurs à la fois et que vous vous appuyez sur un déploiement PostgreSQL existant, l'avantage de pgvector en matière de concurrence en fait le choix le plus sûr. Utilisez les chiffres de ce benchmark pour faire correspondre le magasin à la métrique la plus critique de votre produit.