Qdrant: eine Vektordatenbank, gebaut um Filtern

Qdrant ist eine in Rust geschriebene Vektordatenbank unter Apache-2.0, gebaut um eine Entscheidung, die die meisten Wettbewerber als Nebensache behandeln: Ein Metadatenfilter ist nichts, was man nach dem Retrieval anwendet, sondern etwas, mit dem der Index durchlaufen wird. Heraus kommt das überzeugendste Bild für gefilterte Suche in der Open-Source-Welt, und eine wirklich einfache Betriebsgeschichte – ein Container, eine REST- und gRPC-Schnittstelle, offizielle Clients in sechs Sprachen. Der Preis dieser Fokussierung: Für die dichte Suche gibt es genau eine Indeximplementierung, HNSW, und das verwaltete Angebot rechnet nach Verbrauch statt nach veröffentlichtem Preis. Empfehlung für filterlastige Suche, weniger als Allzweckspeicher.

Es liegt in derselben Schicht wie pgvector, Milvus, Weaviate und Pinecone, aber das Versprechen unterscheidt sich. Weaviate verkauft einen integrierten KI-Speicher mit eingebauter hybrider Suche und Modulen; Milvus verkauft horizontale Skalierung in die Milliarden; Pinecone verkauft null Betrieb. Qdrant verkauft Speichereffizienz und Filterdurchsatz auf einem einzelnen Knoten – ein engeres und leichter haltbares Versprechen.

Was es ist

Das Datenmodell ist absichtlich klein. Ein Punkt ist ein Datensatz mit einem Vektor und einem optionalen JSON-Payload. Eine Collection ist eine benannte Menge von Punkten mit gemeinsamer Dimension und Distanzmetrik. Benannte Vektoren erlauben mehrere Vektoren pro Punkt mit eigener Dimension und Metrik – so wird hybride Suche ausgedrückt. Alles Übrige im Produkt ist Maschinerie, um den nächsten Nachbarn schneller zu finden, ohne zu scannen.

• Lizenz Apache-2.0, in Rust geschrieben, ein Repository mit rund 35.000 Sternen und 7.100 Commits.
• Aktuelle Version 1.19.2 vom 5. Oktober 2026; die Version 1.19 brachte die memory-Tiers, die bestimmen, wo Vektoren, Indizes und Payloads liegen.
• Distanzmetriken sind Dot Product, Cosine, euklidisch und Manhattan; Cosine ist als Dot Product über normalisierte Vektoren implementiert, normalisiert beim Upload.
• Für die dichte Suche wird ausschließlich HNSW verwendet, mit m standardmäßig 16 und ef_construct 100, beides pro Collection und benanntem Vektor überschreibbar.
• Payload-Index-Typen sind keyword, integer, float, bool, geo, datetime, text und uuid, jeweils vor dem Import angelegt, damit das filterbare HNSW sie nutzen kann.
• Hybride und mehrstufige Suche kam mit 1.10 über die Query API: prefetch-Unterabfragen, verschmolzen mit RRF oder DBSF, wobei Prefetches verschachtelt sein können.
• Offizielle Clients gibt es für Python, TypeScript, Rust, Go, Java und .NET über REST auf 6333 und gRPC auf 6334.

Wie eine Anfrage tatsächlich läuft

Die interessante Technik steckt im Query-Planer, und sie zerfällt in drei Fälle. Ein so enger Filter, dass kaum Daten passen, ist mit einem Vollscan besser bedient als mit einem Graphendurchlauf. Ein so weiter Filter, dass fast die ganze Collection passt, kann das HNSW unverändert nutzen. Alles dazwischen – wo mandanten- und sprachbezogene Suche wohnt – ist der Fall, den ein reiner Vektorindex mit Nachfilterung schlecht beherrscht, und der Fall, für den das filterbare HNSW gebaut wurde.

Ein Betriebsdetail aus der mittleren Spalte verursacht mehr Ausfallzeit als jedes Query-Tuning: Payload-Indizes helfen dem HNSW-Graphen nur, wenn sie vor den Daten existierten. Ein Tenant-Feld zu einer bestehenden Collection hinzuzufügen heißt, den Graphen neu bauen zu lassen, damit er filterbewusst wird – bei großen Collections in Stunden gemessen. Das Payload-Schema gehört vor den ersten Upsert geplant, nicht nach dem ersten Vorfall.

Erste Schritte

Ein Container auf 6333 ohne Authentifizierung reicht zum Start, und das ist zugleich das Wichtigste, was vor dem Verlassen des Laptops zu reparieren ist. Die Konfiguration unten legt eine Collection mit TurboQuant auf einem Bit an, indiziert das Tenant-Feld vor dem Import und führt eine gefilterte Anfrage über die Query API aus:

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="chunks",
    vectors_config=models.VectorParams(size=1024, distance=models.Distance.COSINE),
    quantization_config=models.TurboQuantization(
        turbo=models.TurboQuantQuantizationConfig(bits=models.TurboQuantBitSize.BITS1),
    ),
)

# Before ingestion: the HNSW graph can only be filter-aware for
# fields that already have a payload index.
client.create_payload_index(
    collection_name="chunks",
    field_name="tenant",
    field_schema=models.PayloadSchemaType.KEYWORD,
)

client.upsert(
    collection_name="chunks",
    points=[models.PointStruct(id=1, vector=[0.1] * 1024, payload={"tenant": "acme"})],
)

hits = client.query_points(
    collection_name="chunks",
    query=[0.1] * 1024,
    query_filter=models.Filter(
        must=[models.FieldCondition(key="tenant", match=models.MatchValue(value="acme"))],
    ),
    limit=10,
    search_params=models.SearchParams(quantization=models.QuantizationSearchParams(oversampling=2.0)),
).points

Zwei Dinge in diesem Snippet lohnen sich. Die Quantisierung ist eine Collection-Einstellung, die beim Indexieren angewendet wird, und die komprimierten Vektoren liegen neben den Originalen – die Originale bleiben also für ein Rescore vorhanden. Der Parameter oversampling verlangt das Doppelte an Kandidaten aus dem quantisierten Index, bevor neu bewertet wird. Das ist der Hebel, wenn die komprimierte Suche Ergebnisse verliert, die eigentlich drin sein müssten.

Speicher und Quantisierung

Quantisierung ist die wirksamste Einzelmaßnahme vor dem Produktivbetrieb, und Qdrant bietet inzwischen vier Methoden mit wirklich unterschiedlichen Zielkonflikten statt eines einzelnen Binärschalters. Die Produktions-Checkliste führt sie neben einer ehrlichen RAM-Planung und der Indizierung der gefilterten Felder zu den drei Dingen, die man zuerst tun sollte.

Über die Methode hinaus hat 1.19 einen Memory-Tier-Parameter für die quantisierte Kopie eingeführt, und der macht die Quantisierung als RAM-Reduktion brauchbar statt nur als Geschwindigkeitstrick. Die Originale in den Tier cold und die quantisierten Vektoren in pinned legen, dann greift die Suche nur beim Neubewerten der besten Kandidaten auf die Platte zu. Der Datentyp turbo4, der jede Dimension auf der Platte mit vier statt 32 Bit speichert, verkleinert die Plattseite weiter und kostet Recall. Inline-Storage im HNSW-Index, verfügbar seit 1.16, senkt die I/O-Zugriffe weiter, zahlt sich aber nur aus, wenn Vektoren und Index im Tier cold liegen und die Quantisierung aktiv ist; bei höchstens vier Bit je Dimension gehalten, sonst bläht der Index auf.

Selbst hosten und Sicherheit

Die Sicherheitsdokumentation beginnt mit dem Satz, selbst gehostete Open-Source-Installationen seien standardmäßig nicht sicher und nicht produktionsreif, und eine Standardinstanz sei für alle Netzwerkinterfaces ohne konfigurierte Authentifizierung offen. Das ist eine ehrlichere Sicherheitsseite als bei den meisten Datenbankherstellern, und sie kommt mit einer konkreten Checkliste.

• Drei Typen von API-Schlüsseln: Admin, Read-only für reine Abfragedienste und granulare Schlüssel mit Lese- oder Schreibrechten je Collection.
• TLS für den Verkehr in beide Richtungen, dazu eine Netzwerkbindung an ein privates Interface; lokal an 127.0.0.1 binden.
• Audit-Logging der API-Operationen in eine Datei, für Forensik und Nachweispflichten statt für Erkenntnisse.
• Auf Qdrant Cloud funktioniert all das genauso, dort sind die Kontrollen standardmäßig aktiv – das ist das eigentliche Argument für das verwaltete Angebot.
• Die Support-Tiers Community, Standard und Premium unterscheiden sich in der Reaktionszeit (vier Stunden bei einem Totalausfall im kostenlosen Tier, eine Stunde in Standard), nicht im Funktionsumfang.

Wo es schwächelt

Fünf Schwächen sind klar zu benennen, denn sie sind es, die dagegen entscheiden.

• Ein dichter Index. Die Dokumentation sagt, Qdrant nutze für dichte Vektoren ausschließlich HNSW. Es gibt kein IVF, keinen Graphen auf Platte und keinen GPU-Index; ein Korpus, der nicht in den Arbeitsspeicher einer Maschine passt, braucht einen Architekturwechsel statt einer Einstellung.
• Payload-Indizes entstehen vor dem Import oder gar nicht. Die Wirksamkeit der Optimierung hängt von einer Migration ab, die man zu terminieren vergisst.
• Horizontale Skalierung gibt es, aber nicht umsonst. Shards, Replikationsfaktoren und shard-key-bewusste Lesezugriffe sind Konfiguration, die stimmen muss, und die Kapazitätsseite verlangt, all das vor der Provisionierung zu entscheiden.
• Das verwaltete Angebot veröffentlicht keinen Preis. Es wird stundenweise nach vCPU, Arbeitsspeicher, Speicher, Backups und Inferenz-Token abgerechnet, mit einem Rechner statt einer Preisliste, und Serverless steht weiterhin als kommend in der Navigation.
• Der öffentliche Benchmark ist veraltet. Die Vergleichsseite des Herstellers trägt Januar und Juni 2024; ihr Fazit, Qdrant führe bei Durchsatz und Latenz, beschreibt Software von vor zwei Jahren.

Die Kurzfassung: pgvector, wenn Sie bereits Postgres betreiben und der Korpus hineinpasst; Weaviate, wenn native hybride Suche die Anforderung ist; Milvus, wenn die Zahlen wirklich in die Hunderten von Millionen gehen; Pinecone, wenn niemand etwas betreiben will. Qdrant ist die Wahl dazwischen, wo ein Metadatenfilter bei jeder Anfrage wichtiger ist als die Obergrenze.

Fazit

Qdrant ist die beste Open-Source-Antwort auf gefilterte Vektorsuche, und ihre Schwächen liegen alle in Bereichen, in denen es nicht gewinnen will. Steht auf praktisch jeder Anfrage ein Tenant, eine Sprache oder ein Datum – in Produktion fast immer –, ist das filterbare HNSW ein echter Architekturvorteil und kein Häkchen in einer Feature-Liste. Wählen Sie es wissend, dass die dichte Suche genau einen Index hat, das Payload-Schema an Tag eins stimmen muss und Sie die Sicherheits-Checkliste selbst abarbeiten.

1. Wählen, wenn auf praktisch jeder Anfrage ein Metadatenfilter liegt und der Korpus auf eine Maschine passt, mit Reserve.
2. Wählen, wenn Sie keine Lizenzverhandlung wollen: Apache-2.0, keine Feature-Schranke, kein Telemetrie-Zwang, keine Nutzungsberichte.
3. Wählen, wenn Ihr Team API-Schlüssel, TLS-Zertifikat, Backup-Zeitplan und Versions-Upgrade selbst verantwortet.
4. Nicht wählen, wenn der Korpus den Arbeitsspeicher sprengen wird und niemand Lust auf eine Migration zu einer verteilten Engine hat.
5. Nicht auf Basis eines Benchmarks wählen. Prüfen Sie den Recall im exakten Modus an Ihren eigenen Embeddings, dann entscheiden Sie.

Selbst gehostete Open-Source-Installationen sind standardmäßig nicht sicher und nicht produktionsreif. Alle selbst aufgesetzten Qdrant-Instanzen sind standardmäßig für alle Netzwerkinterfaces offen und haben keine konfigurierte Authentifizierung.

Quellen

1. Qdrant Dokumentation
2. Qdrant: Points
3. Qdrant: Collections
4. Qdrant: Indizierung, Payload-Indizes und das filterbare HNSW
5. Qdrant: Quantisierungsmethoden und Memory-Tiers
6. Qdrant: Kapazitätsplanung
7. Qdrant: Leistung optimieren
8. Qdrant: hybride und mehrstufige Abfragen
9. Qdrant: Filterklauseln
10. Qdrant: Sicherheit und Zugriffskontrolle
11. Qdrant Preise: kostenlos, Standard und Premium
12. Qdrant auf GitHub
13. Qdrant Vektor-Benchmarks