Polydesk-logotype
Polydesk.ai — Header

Qdrant

Qdrant (prononcé « quadrant ») est un moteur de recherche vectorielle open source (licence Apache 2.0) entièrement écrit en Rust, conçu pour offrir des performances élevées, une faible empreinte mémoire et une recherche vectorielle composable à grande échelle.

Qdrant se distingue de la concurrence par deux choix fondamentaux : Rust comme langage de programmation (performances prévisibles, sécurité mémoire, pas de garbage collector) et une philosophie de composabilité (chaque couche du retrieval est un composant configurable). Le résultat : un vector store qui s’adapte à votre problème plutôt que de forcer votre problème à rentrer dans l’outil. En mars 2026, Qdrant a levé 50 millions de dollars en Série B, portant son financement total à 87,8 millions de dollars, signe de la confiance du marché dans son approche.

Qdrant en bref
Catégorie
Vector Store / Moteur de recherche vectorielle
Licence
Apache 2.0
Langage
Rust (moteur), clients Python/JS/Rust/Go/.NET/Java
Déploiement
Docker, Kubernetes, binaire natif, Qdrant Cloud, Hybrid Cloud, Private Cloud
Pricing Cloud
Free tier (1 Go) → ~$25/mois (managed) → Enterprise sur devis
Financement
$87,8M total (Série B mars 2026, menée par AVP)
Fonctionnalités clés
HNSW filtrable, hybrid search (dense + sparse), quantization avancée, payloads JSON, multi-vector
Alternatives
Pinecone, Weaviate, Milvus, ChromaDB, pgvector
URL
qdrant.tech

Pourquoi Rust fait la différence

Le choix de Rust n’est pas un détail marketing. Pour un moteur de recherche vectorielle, le langage de programmation impacte directement trois dimensions critiques :

Empreinte mémoire. Rust ne nécessite pas de garbage collector. Les benchmarks montrent que Qdrant utilise 2 à 3 fois moins de mémoire que les vector stores écrits en Go (comme Weaviate) pour un même volume de données. Quand vous stockez des millions de vecteurs de 1536 dimensions, cette différence se traduit directement en coût d’infrastructure.

Latence prévisible. L’absence de garbage collector élimine les pauses imprévisibles qui peuvent faire monter la latence p99 de manière erratique. Les applications qui exécutent des milliers de requêtes par seconde dans des boucles d’agents IA ont besoin de cette prévisibilité.

Performances brutes. Qdrant exploite les instructions SIMD (Single Instruction, Multiple Data) du processeur pour accélérer les calculs de distance vectorielle. Le moteur de stockage custom (Gridstore) est optimisé spécifiquement pour les patterns d’accès des données vectorielles. Le résultat : jusqu’à 4x le débit en requêtes par seconde (RPS) comparé à certains concurrents dans les benchmarks.


Fonctionnalités principales

HNSW filtrable (pas de pre/post-filtering)

L’une des fonctionnalités les plus distinctives de Qdrant. La plupart des vector stores appliquent les filtres soit avant la recherche vectorielle (pre-filtering, qui peut fragmenter le graphe HNSW et dégrader le recall) soit après (post-filtering, qui gaspille du compute en cherchant des résultats qui seront ensuite éliminés). Qdrant applique les filtres pendant la traversée du graphe HNSW. Cela garantit un recall élevé avec une latence faible même avec des conditions de filtrage complexes.

Qdrant supporte nativement les vecteurs denses (embeddings classiques pour la similarité sémantique) et les vecteurs sparse (BM25, SPLADE++, miniCOIL pour le keyword matching). Les deux types de vecteurs peuvent être combinés dans une seule requête pour une recherche hybride qui allie compréhension sémantique et correspondance exacte de termes.

Multi-vector par objet

Chaque objet dans Qdrant peut contenir plusieurs vecteurs nommés (par exemple, un vecteur pour le titre et un autre pour le contenu, ou un vecteur texte et un vecteur image). Les requêtes peuvent cibler un vecteur spécifique ou combiner les scores de plusieurs vecteurs. Cette fonctionnalité est essentielle pour les applications multimodales et les modèles d’interaction tardive (late interaction) comme ColBERT.

Payloads JSON riches

Chaque vecteur dans Qdrant est accompagné d’un payload JSON arbitraire : texte, nombres, dates, géolocalisation, listes, objets imbriqués. Ces payloads sont indexables et filtrables. Vous pouvez chercher des vecteurs similaires tout en filtrant par category = "technique" ET price < 100 ET location NEAR (48.8, 2.3). Cette flexibilité élimine le besoin d’une base de données séparée pour les métadonnées.

Quantization avancée

Qdrant propose trois méthodes de quantization pour réduire l’empreinte mémoire :

Scalar Quantization (SQ) : convertit les vecteurs float32 en int8, réduisant la mémoire de 4x avec un impact minimal sur le recall.

Product Quantization (PQ) : compresse les vecteurs en sous-vecteurs quantifiés, réduction de 8 à 64x selon la configuration.

Binary Quantization (BQ) : propriété unique de Qdrant, réduit chaque dimension à un seul bit. Réduction de mémoire de 32x avec des performances de recherche accélérées jusqu’à 40x. Particulièrement efficace avec les modèles d’embedding de haute dimension (1536+).

Avec la quantization, un cluster de 64 Go de RAM peut contenir 100 millions de vecteurs de 768 dimensions. Sans quantization, le même cluster en contiendrait ~20 millions.

Indexation en temps réel

Les vecteurs ajoutés à Qdrant sont recherchables immédiatement, sans reconstruction d’index. C’est critique pour les applications où les données changent fréquemment (tickets de support, inventaire produit, feed d’actualités). Certains vector stores nécessitent un rebuild d’index après l’ajout de données, introduisant un délai entre l’ingestion et la disponibilité.


Utilisation concrète

from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, PointStruct,
    Filter, FieldCondition, MatchValue, Range
)

# 1. Connexion (local Docker ou Cloud)
client = QdrantClient(url="http://localhost:6333")
# Ou : client = QdrantClient(url="https://xyz.cloud.qdrant.io", api_key="KEY")

# 2. Créer une collection avec dense + sparse
client.create_collection(
    collection_name="products",
    vectors_config={
        "description": VectorParams(size=1536, distance=Distance.COSINE),
    },
    sparse_vectors_config={
        "keywords": {}  # Pour la recherche BM25/SPLADE
    }
)

# 3. Upsert avec payloads riches
client.upsert(
    collection_name="products",
    points=[
        PointStruct(
            id=1,
            vector={"description": [0.12, -0.34, ...]},  # 1536 dims
            payload={
                "name": "Chaussures de randonnée GTX",
                "category": "outdoor",
                "price": 129.99,
                "brand": "Salomon",
                "in_stock": True,
                "tags": ["waterproof", "hiking", "gore-tex"]
            }
        ),
    ]
)

# 4. Recherche vectorielle avec filtrage avancé
results = client.query_points(
    collection_name="products",
    query=[0.11, -0.33, ...],  # embedding de la requête
    using="description",
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="outdoor")),
            FieldCondition(key="price", range=Range(lte=150.0)),
            FieldCondition(key="in_stock", match=MatchValue(value=True)),
        ]
    ),
    limit=5
)

for point in results.points:
    print(f"{point.payload['name']} - {point.payload['price']}€ - Score: {point.score:.3f}")
# Mode in-memory pour le prototypage (sans Docker)
from qdrant_client import QdrantClient

client = QdrantClient(":memory:")  # Tout en RAM, parfait pour les tests

# Ou persistant sur disque sans serveur
client = QdrantClient(path="./qdrant_data")  # Sauvegarde sur disque

Options de déploiement

Self-hosted

Qdrant est distribué comme un binaire Rust unique ou une image Docker. Le démarrage est immédiat :

# Docker (méthode recommandée)
docker run -p 6333:6333 -p 6334:6334 
  -v $(pwd)/qdrant_storage:/qdrant/storage:z 
  qdrant/qdrant

# Kubernetes (production)
helm repo add qdrant https://qdrant.to/helm
helm install qdrant qdrant/qdrant

Pour la production, un cluster de 3 nœuds minimum assure la haute disponibilité via le protocole Raft. Le scaling horizontal s’effectue par sharding (distribution des données) et réplication (copies redondantes). Les mises à jour se font en rolling update sans interruption de service.

Qdrant Cloud

Qdrant Cloud est le service managé, disponible sur AWS, GCP et Azure. Il offre un free tier (1 Go, suffisant pour ~50 000 vecteurs de 1536 dimensions) et des clusters managés à partir de ~25 $/mois avec backups automatiques, monitoring et scaling vertical/horizontal.

Le pricing est basé sur les ressources (RAM, CPU, disque) plutôt que sur le nombre de requêtes ou de vecteurs. Ce modèle est plus prévisible que le pricing par Read Unit (Pinecone) car le coût est fixe indépendamment du volume de requêtes. Pour les workloads à haut débit, c’est un avantage économique significatif.

Hybrid Cloud et Private Cloud

Pour les organisations avec des exigences de souveraineté des données, Qdrant propose Hybrid Cloud (management Qdrant dans votre infrastructure cloud) et Private Cloud (déploiement complètement isolé). Ces options satisfont les exigences de conformité (SOC 2, HIPAA, RGPD) des industries réglementées.


Cas d’usage en production

RAG pour agents IA. Les agents IA exécutent des milliers de requêtes vectorielles par workflow contre des données qui changent continuellement. La latence prévisible et l’indexation en temps réel de Qdrant sont conçues exactement pour ce pattern.

Recommandation e-commerce. Canva utilise Qdrant pour standardiser son infrastructure de recherche vectorielle et servir des millions d’utilisateurs. Les payloads riches permettent de combiner similarité visuelle et filtres métier (prix, catégorie, disponibilité) en une seule requête.

Recherche sémantique à grande échelle. La quantization binaire permet de stocker des centaines de millions de vecteurs avec un budget RAM raisonnable, rendant la recherche sémantique accessible sur des corpus massifs (documentation technique enterprise, catalogues de millions de produits).

Détection d’anomalies et deduplication. L’indexation en temps réel et le filtrage par payload permettent de détecter les doublons ou les anomalies en continu : chaque nouveau document est comparé aux existants avec des contraintes métier.


Forces et limites

Points forts

Performance et efficacité mémoire. Rust + SIMD + Gridstore = le meilleur ratio performance/coût du marché en self-hosted. Les benchmarks montrent des latences p99 de 30 à 40ms, contre 50 à 70ms pour Weaviate et des latences variables pour Pinecone.

HNSW filtrable. Le filtrage pendant la traversée HNSW (pas avant, pas après) est un avantage technique réel pour les requêtes qui combinent similarité et contraintes métier. C’est la fonctionnalité qui fait la différence en production.

Pricing prévisible. Le modèle basé sur les ressources (pas sur les requêtes) est plus facile à budgéter. Le free tier (1 Go) est permanent, pas un trial de 14 jours.

Flexibilité de déploiement. Du prototype en mémoire au cluster Kubernetes distribué, en passant par le cloud managé et le private cloud. Qdrant s’adapte à tous les contextes.

Composabilité. Dense vectors, sparse vectors, multi-vectors, score boosting, late interaction models : Qdrant expose chaque couche du retrieval comme un composant configurable. Les ingénieurs contrôlent directement les compromis recall/latence/coût.

Limites

Pas de vectorisation intégrée. Contrairement à Weaviate (modules de vectorisation) ou Pinecone (Inference), Qdrant ne génère pas les embeddings pour vous. Vous devez calculer les vecteurs côté client avant de les envoyer. C’est un composant supplémentaire dans votre architecture.

Pas de RAG natif. Qdrant fait de la recherche vectorielle, pas de la génération. Pour un pipeline RAG complet, vous avez besoin d’un framework externe (LangChain, LlamaIndex) pour orchestrer retrieval + LLM. Weaviate et Pinecone intègrent cette fonctionnalité nativement.

Communauté plus petite. Qdrant a une communauté plus petite que Pinecone ou Weaviate, ce qui signifie moins de tutoriels, moins d’exemples de code et un écosystème d’intégrations moins large (bien que les intégrations principales soient bien supportées).


Qdrant vs alternatives

Critère Qdrant Pinecone Weaviate pgvector
Langage Rust Propriétaire Go C (extension PG)
Open source Apache 2.0 Non BSD-3 PostgreSQL
Latence p99 30-40ms 20-100ms (variable) 50-70ms Variable
Mémoire/vecteur La plus basse (Rust) N/A (managé) 2-3x plus que Qdrant Dépend de PG
Filtrage HNSW Pendant la traversée Post-filtering Pre-filtering Post-filtering SQL
Vectorisation auto Non Oui (Inference) Oui (modules natifs) Non
Binary Quantization Oui (unique) Non Non Non
Pricing Free tier + ressources $50/mois min + RU $45/mois min + dimensions Inclus dans PG
Cas idéal Performance, contrôle, coût-efficacité Zéro ops, production rapide AI-native, RAG intégré Déjà sur PostgreSQL
Quand choisir Qdrant Qdrant est le meilleur choix quand : la performance et l’efficacité mémoire sont prioritaires (vous voulez le maximum de vecteurs par dollar d’infrastructure), vous avez besoin de filtrage complexe en production (combinaison similarité + contraintes métier), vous voulez un pricing prévisible basé sur les ressources (pas sur les requêtes), ou vous construisez des applications pour des agents IA qui exécutent des milliers de requêtes vectorielles par workflow.

Verdict

Qdrant est le vector store qui offre le meilleur rapport performance/coût en 2026, surtout en self-hosted. Le fondement Rust, le HNSW filtrable, la binary quantization et le pricing basé sur les ressources en font le choix des équipes d’ingénierie qui veulent contrôler leur infrastructure et optimiser leurs coûts sans sacrifier la performance.

Le compromis : Qdrant est un moteur de recherche vectorielle, pas une plateforme RAG complète. Il ne génère pas vos embeddings et ne fait pas de génération. Vous devez assembler le pipeline RAG vous-même (embedding → Qdrant → LLM). Pour les équipes qui veulent une solution tout-en-un, Weaviate ou Pinecone sont plus intégrés. Pour les équipes qui veulent le contrôle total sur chaque couche du retrieval, Qdrant est imbattable.

La levée de 50M$ en mars 2026 confirme la trajectoire. Qdrant est utilisé en production par Canva, Microsoft, Bayer et des milliers d’autres organisations. C’est un choix de production éprouvé, pas un outil de niche.


Questions fréquentes sur Qdrant

Qdrant est-il gratuit ?

Le logiciel Qdrant est open source (licence Apache 2.0) et gratuit. Vous pouvez le self-hoster sur votre propre infrastructure sans aucun frais de licence. Qdrant Cloud propose un free tier permanent de 1 Go (suffisant pour ~50 000 vecteurs de 1536 dimensions). Les clusters managés commencent à environ 25 $/mois. L’open source offre la même parité fonctionnelle que le cloud.

Qdrant ou Pinecone : lequel choisir ?

Pinecone est le meilleur choix si vous ne voulez aucune opération d’infrastructure et que vous voulez être en production en quelques minutes. Qdrant est le meilleur choix si vous voulez des performances supérieures, un pricing plus prévisible (basé sur les ressources, pas sur les requêtes), et le contrôle de votre infrastructure. Pour les workloads à haut débit, Qdrant self-hosted est significativement moins cher que Pinecone car le coût est fixe indépendamment du nombre de requêtes.

Combien de vecteurs Qdrant peut-il gérer ?

Un seul nœud Qdrant peut gérer des dizaines de millions de vecteurs selon la dimensionnalité et la RAM disponible. Avec la quantization binaire, 100 millions de vecteurs de 768 dimensions tiennent dans un cluster de 64 Go de RAM. Pour les milliards de vecteurs, le mode distribué (sharding + réplication sur Kubernetes) scale horizontalement. Qdrant revendique le support de milliards de vecteurs avec une empreinte mémoire minimale grâce à l’architecture de stockage optimisée.

Comment fonctionne la Binary Quantization de Qdrant ?

La Binary Quantization (BQ) est une technique unique à Qdrant qui réduit chaque dimension d’un vecteur float32 (32 bits) à un seul bit (1 bit). Le résultat : une réduction de mémoire de 32x et une accélération de la recherche de 40x car les opérations de distance se réduisent à des opérations XOR sur des entiers, extrêmement rapides sur les processeurs modernes. Le recall diminue légèrement (3-5% selon les modèles d’embedding), mais pour la majorité des applications RAG, cette perte est imperceptible et le gain en coût/performance est massif.

Qdrant est-il adapté pour les agents IA ?

Oui, c’est l’un des cas d’usage pour lesquels Qdrant est spécifiquement conçu. Les agents IA exécutent des milliers de requêtes vectorielles par workflow contre des données qui changent en continu. Qdrant offre l’indexation en temps réel (les nouveaux vecteurs sont recherchables immédiatement), la latence prévisible (pas de pauses garbage collector), et la composabilité (combiner vecteurs denses, sparse et filtres dans chaque requête). L’intégration avec LangChain, LlamaIndex et les SDK d’agents est native.

Polydesk.ai — Footer