> Elasticsearch und OpenSearch als Vektorspeicher: kNN und Filter, BBQ und binäre Quantisierung, hybride Suche mit RRF, GPU-Builds und die Lizenzfrage. > > Web page: https://balazscsorba.com/de/blog/elasticsearch-opensearch-vector-search · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/elasticsearch-opensearch-vector-search.md) · [Magyar](https://balazscsorba.com/hu/blog/elasticsearch-opensearch-vector-search.md) > Author: Balázs Csorba · Published: 2026-09-30 · Updated: 2026-10-01 · Keywords: vector search in Elasticsearch and OpenSearch, elasticsearch knn vector search, opensearch neural search, hybrid search rrf, elasticsearch bbq better binary quantization, opensearch diskann jvector, elasticsearch agpl license, filtered knn search, elasticsearch vs opensearch vector database, search engine as vector store [Blog](https://balazscsorba.com/de/blog)/Retrieval & Suche # Vektorsuche in Elasticsearch und OpenSearch: kNN, hybride Suche und die Lizenzfrage Elasticsearch und OpenSearch als Vektorspeicher: kNN und Filter, BBQ und binäre Quantisierung, hybride Suche mit RRF, GPU-Builds und die Lizenzfrage. [Balázs Csorba](https://balazscsorba.com/de/about)·30\. September 2026·aktualisiert 1\. Oktober 2026·8 Min. Lesezeit - Elasticsearch - OpenSearch - Vector search - Hybrid search - Licensing ![Ein Schrank mit einer Text- und einer Vektorschublade, durchsucht von einer Lupe.](https://balazscsorba.com/images/blog/elasticsearch-opensearch-vector-search/cover.webp?v=eefa64abde) ## Das Wichtigste in Kürze - Wenn Sie Elasticsearch oder OpenSearch bereits für Produkt- oder Seitensuche betreiben, ist das eingebaute kNN meist der erste Vektorspeicher, den man testet, weil hybride Suche und Filter dabei sind. - In Elasticsearch wird ein Filter innerhalb der kNN-Klausel während der Graphsuche angewendet und liefert k Treffer; ein Filter daneben läuft danach und kann weniger liefern. - Quantisierung bestimmt die Speicherrechnung: Elasticsearch nutzt seit 9.1 für 384 oder mehr Dimensionen standardmäßig BBQ, OpenSearch bietet 32-fache On-Disk-Kompression und binäre Quantisierung mit 1, 2 oder 4 Bit. - Beide Engines fusionieren BM25- und Vektortreffer per RRF; OpenSearchs eigener BEIR-Test fand RRF im Schnitt 3,86 Prozent unter der wertbasierten Normalisierung. - Die Lizenzen unterscheiden sich: OpenSearch ist Apache-2.0, Elasticsearch bietet seit August 2024 AGPL, SSPL oder ELv2, und mehrere Vektorfunktionen wie DiskBBQ und GPU-Indexierung brauchen ein Elastic-Enterprise-Abo. Auf dieser Seite 1. [Brauchen Sie eine Vektordatenbank, wenn schon ein Suchcluster läuft?](https://balazscsorba.com/#do-you-need-a-vector-database) 2. [Wie kNN und Filterung in beiden Engines funktionieren](https://balazscsorba.com/#how-knn-works) 3. [Bei der Quantisierung entscheidet sich der Speicher](https://balazscsorba.com/#quantization-and-memory) 4. [Hybride Suche mit RRF](https://balazscsorba.com/#hybrid-search-with-rrf) 5. [GPU-Indexaufbau und Ingestion](https://balazscsorba.com/#gpu-and-ingestion) 6. [Die Lizenzgeschichte und was sie für Sie bedeutet](https://balazscsorba.com/#licensing) 7. [Wann Elasticsearch oder OpenSearch der falsche Vektorspeicher ist](https://balazscsorba.com/#when-not-to-use) 8. [Eine praktische Checkliste](https://balazscsorba.com/#checklist) 9. [Quellen](https://balazscsorba.com/#sources) Diesen Artikel anhören 0:000:00 **Vektorsuche in Elasticsearch und OpenSearch** heißt, die Suchmaschine, die Sie vielleicht schon betreiben, als Vektorspeicher zu nutzen: ein Feld `dense_vector` oder `knn_vector` neben den Textfeldern, approximative Nächste-Nachbarn-Suche darauf und hybrides Ranking mit BM25 in derselben Anfrage. Für einen Shop oder eine Website mit vorhandenem Suchcluster ist das oft einfacher als eine separate Vektordatenbank, solange Speicher und Lizenz passen. Dieser Artikel behandelt, wie kNN und Filterung in beiden Engines funktionieren, wo Quantisierung die Speicherrechnung verschiebt, hybride Fusion mit RRF, GPU-Indexaufbau, die Lizenzgeschichte von 2021 bis 2024 und wann ein eigener Speicher die bessere Wahl ist. Eigene Vektorspeicher vergleichen [pgvector gegen Vektordatenbanken](https://balazscsorba.com/de/blog/pgvector-vs-vector-databases) und die [Besprechung von Milvus und Zilliz](https://balazscsorba.com/de/blog/milvus-zilliz). Versionen Stand Oktober 2026: Elasticsearch 9.5 und OpenSearch 3.9. ## Brauchen Sie eine Vektordatenbank, wenn schon ein Suchcluster läuft? Oft nicht. Liegt Ihre Textsuche bereits in Elasticsearch oder OpenSearch, bringt ein Vektorfeld semantische Suche, Schlüsselwortsuche, Filter auf strukturierte Felder und Fusion in einer Anfrage, mit einem System zum Betreiben und Sichern. Der Preis ist Speicher: Approximatives kNN mit HNSW arbeitet nur dann effizient, wenn die Vektordaten in den Page Cache des Knotens passen ([Elastic](https://www.elastic.co/docs/solutions/search/vector/knn/approximate-knn)). Diese eine Bedingung bestimmt die meisten Entscheidungen unten. B2B-Produktsuche ist der typische Fall: Anfragen mischen Teilenummern, Markenfilter und lose Beschreibungen, also brauchen Schlüsselwort- und Vektorsuche einander. Dieses Muster beschreibt [semantische Produktsuche im B2B](https://balazscsorba.com/de/blog/semantic-product-search-b2b). Viele Shops auf Spryker- oder Pimcore-Basis betreiben für den Katalog bereits einen solchen Cluster, was die eingebaute Vektorunterstützung zum naheliegenden ersten Experiment macht. Betrieblich bedeutet ein Cluster auch ein Backup-Konzept, ein Zugriffsmodell und einen Ort, an dem Dokumente aktualisiert werden. Ändert sich ein Produkt, werden Textfelder und Embedding im selben Dokument-Update geschrieben, Schlüsselwortindex und Vektorindex können also nicht auseinanderlaufen. Mit einer separaten Vektordatenbank müssen Sie diese Synchronisation selbst bauen und überwachen, Löschungen eingeschlossen, und genau dort entstehen die meisten Fehler mit veralteten Treffern. ## Wie kNN und Filterung in beiden Engines funktionieren Elasticsearch bietet drei Einstiegspunkte für approximatives kNN, die Top-Level-Option `knn`, eine `knn`\-Query und einen `knn`\-Retriever, dazu exaktes Brute-Force-kNN für kleine Kandidatenmengen; approximative Suche ist für `dense_vector`\-Felder standardmäßig aktiv ([Elastic](https://www.elastic.co/docs/solutions/search/vector/knn)). Die wichtigste Einstellung ist, wo der Filter steht. Ein Filter innerhalb der kNN-Klausel wird während der approximativen Suche angewendet, Sie bekommen also k passende Dokumente. Ein Filter neben der kNN-Klausel in einer `bool`\-Query läuft danach und kann weniger als k liefern ([Elastic](https://www.elastic.co/docs/solutions/search/vector/knn/filtered-knn-search)). ![Anfragepfade in Elasticsearch und OpenSearch Zwei Bahnen. Obere Bahn, Elasticsearch: eine Anfrage mit kNN-Klausel und Filter darin; der Filter wird beim Durchlaufen des HNSW-Graphen angewendet; das Ergebnis sind k passende Dokumente, die ein RRF-Retriever mit einem BM25-Retriever fusioniert. Untere Bahn, OpenSearch: eine hybride Anfrage mit BM25-Teil und knn_vector-Teil; beide laufen; eine Search Pipeline normalisiert die Werte oder wendet den Score-Ranker-RRF-Prozessor an; die fusionierte Liste kommt zurück.](https://balazscsorba.com/images/blog/elasticsearch-opensearch-vector-search/diagram-8.webp?v=b1e31052be) Elasticsearch filtert während des Graphdurchlaufs und fusioniert mit Retrievern; OpenSearch führt beide Hälften einer hybriden Anfrage aus und fusioniert in einer Search Pipeline. Der zweite Regler ist `num_candidates`: wie viele Kandidaten jeder Shard aus dem Graphen sammelt, bevor die Top-k gewählt werden. Ein höherer Wert verbessert den Recall und kostet Latenz, und es ist die erste Einstellung, die man justiert, wenn Ergebnisse leicht danebenliegen. Halten Sie k nahe an dem, was Sie tatsächlich anzeigen oder weitergeben, etwa 50 für einen Reranker oder 10 für eine Antwort, und setzen Sie `num_candidates` auf das Zwei- bis Vierfache, während Sie den Recall auf einer Stichprobe gegen exaktes kNN messen. OpenSearch lässt Sie pro Feld eine Engine wählen: Lucene mit HNSW und effizienter nativer Filterung, Faiss mit HNSW und IVF plus Skalar-, Produkt- und Binär-Encodern, das veraltete NMSLIB und JVector, eine reine Java-Engine im DiskANN-Stil mit Produktquantisierung und gleichzeitigen Inserts ([OpenSearch](https://docs.opensearch.org/latest/mappings/supported-field-types/knn-methods-engines/)). Für die meisten neuen Indizes sind Lucene oder Faiss der Startpunkt; JVector ist die Option, wenn der Index überwiegend auf der Platte liegen soll. ## Bei der Quantisierung entscheidet sich der Speicher Beide Engines quantisieren inzwischen standardmäßig oder mit einer Einstellung, und die Standards haben sich schnell geändert. In Elasticsearch war in 9.0 `int8_hnsw` Standard; ab 9.1 ist es `bbq_hnsw` für Vektoren mit 384 oder mehr Dimensionen und sonst `int8_hnsw`; ab 9.4 ist es `bbq_disk`, sofern die Lizenz es erlaubt ([Elastic](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/dense-vector)). BBQ kam mit 8.16 im September 2024 mit bis zu 32-facher Kompression ([Elastic](https://www.elastic.co/blog/whats-new-elastic-search-8-16-0)), und die Doku beziffert die Speicherersparnis auf 96 Prozent pro Dimension, wobei die Rohvektoren für das Rescoring auf der Platte bleiben ([BBQ](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/bbq)). ![Speicher pro Vektor je Quantisierungsstufe Vier Stufen von links nach rechts: rohe float32-Vektoren in voller Größe; int8-Skalarquantisierung bei etwa einem Viertel, der Standard in Elasticsearch 9.0; int4 bei etwa einem Achtel; und ein Bit pro Dimension mit BBQ oder binärer Quantisierung, bis zu 32-mal kleiner, seit 9.1 der Elasticsearch-Standard ab 384 Dimensionen und der On-Disk-Standard von OpenSearch für float-Vektoren.](https://balazscsorba.com/images/blog/elasticsearch-opensearch-vector-search/diagram-13.webp?v=aff4bec829) Jede Stufe tauscht Speicher gegen Recall, den das Rescoring gegen die Rohvektoren auf der Platte zurückholt. DiskBBQ, der Typ `bbq_disk`, clustert Vektoren mit hierarchischem k-Means auf der Platte, zielt auf Recall bis etwa 95 Prozent und braucht ein Enterprise-Abo ([BBQ](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/bbq)). OpenSearch erreicht ähnliche Verhältnisse anders: Speicheroptimierte Vektoren nutzen im Modus `in_memory` standardmäßig 1-fache und im Modus `on_disk` für `float` 32-fache Kompression, mit einem Oversampling-Faktor von 2,0 beim Rescoring bei 32x ([OpenSearch](https://docs.opensearch.org/latest/mappings/supported-field-types/knn-memory-optimized/)), und die binäre Quantisierung von Faiss unterstützt 1, 2 oder 4 Bit für 32-, 16- oder 8-fache Kompression ([OpenSearch](https://docs.opensearch.org/latest/vector-search/optimizing-storage/binary-quantization/)). Eine grobe Größenrechnung hilft vor der Wahl der Stufe. Eine Million float32-Vektoren mit 1.024 Dimensionen belegen roh etwa 4 GB, als int8 etwa 1 GB und bei einem Bit pro Dimension etwa 128 MB, zuzüglich Graph-Overhead. Für einen Katalog mit einigen hunderttausend Produkten passt int8 oft bequem und hält den Recall hoch; BBQ lohnt sich ab Millionen Vektoren oder auf kleinen Knoten, wo es darüber entscheidet, ob der Index überhaupt in den Speicher passt. Einen neutralen direkten Benchmark von BBQ gegen die Quantisierung in OpenSearch habe ich bei der Recherche nicht gefunden; was es gibt, veröffentlichen die Anbieter selbst. Messen Sie Recall bei Ihrem k mit Ihren eigenen Vektoren vor und nach dem Wechsel der Stufe und lassen Sie das Rescoring eingeschaltet. ## Hybride Suche mit RRF Beide Engines fusionieren Schlüsselwort- und Vektortreffer, aber an unterschiedlichen Stellen. Elasticsearch hat Reciprocal Rank Fusion in 8.8 ergänzt und mit Retrievern in 8.16 allgemein verfügbar gemacht; der `rrf`\-Retriever braucht mindestens zwei Kind-Retriever, setzt `rank_constant` standardmäßig auf 60 und unterstützt kein `sort`, `scroll` oder `rescore` ([Elastic](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion)). OpenSearch fusioniert in einer Search Pipeline: wertbasierte Normalisierung seit 2.10 und RRF als Score-Ranker-Prozessor seit 2.19. ``` PUT products { "mappings": { "properties": { "title": { "type": "text" }, "brand": { "type": "keyword" }, "embedding": { "type": "dense_vector", "dims": 1024, "similarity": "cosine", "index_options": { "type": "bbq_hnsw" } } } } } GET products/_search { "retriever": { "rrf": { "retrievers": [ { "standard": { "query": { "match": { "title": "Kugelhahn DN50 Edelstahl" } } } }, { "knn": { "field": "embedding", "query_vector": [/* 1024 floats */], "k": 50, "num_candidates": 200, "filter": { "term": { "brand": "acme" } } } } ], "rank_constant": 60 } } } ``` OpenSearch hat einen nützlichen Vergleich veröffentlicht: Auf sechs BEIR-Datensätzen lag RRF im Schnitt 3,86 Prozent unter dem NDCG@10 der wertbasierten hybriden Pipeline, bei vergleichbarer Latenz ([OpenSearch](https://docs.opensearch.org/latest/vector-search/ai-search/hybrid-search/rrf/)). RRF bleibt der sicherere Standard, wenn die Wertskalen stark voneinander abweichen, weil es Werte ganz ignoriert. Soll ein Modell die fusionierte Liste danach verfeinern, siehe [Cross-Encoder-Reranker im Vergleich](https://balazscsorba.com/de/blog/reranking-models-compared). In der Praxis zeigen sich Relevanzprobleme zuerst bei der Fusion. Eine Anfrage, die nur aus einer Teilenummer besteht, sollte BM25 gewinnen, eine vage Beschreibung die Vektorsuche, und RRF bewältigt beides ohne Tuning. Protokollieren Sie für eine Stichprobe echter Anfragen, welcher Retriever welchen Treffer beigesteuert hat; trägt eine Seite nie bei, ist entweder ihre Anfrage falsch oder sie ist ihre Kosten nicht wert. ## GPU-Indexaufbau und Ingestion Der Aufbau von HNSW-Graphen ist der teure Teil der Ingestion, und beide Projekte lagern ihn inzwischen an NVIDIA cuVS aus. In Elasticsearch war GPU-Vektorindexierung in 9.3 eine Vorschau und ist seit 9.4 allgemein verfügbar; sie braucht ein Enterprise-Abo, Linux auf x86\_64, eine GPU ab Ampere mit mindestens 8 GB und funktioniert nur für `hnsw` und `int8_hnsw` mit `float`\-Elementen ([Elastic](https://www.elastic.co/docs/solutions/search/vector/gpu-vector-indexing)). OpenSearch lieferte GPU-Beschleunigung in 3.0 als Vorschau und in 3.1 produktionsreif und meldet bis zu 9,3-mal schnelleren und 3,75-mal günstigeren Indexaufbau als nur mit CPU ([OpenSearch](https://opensearch.org/blog/gpu-accelerated-vector-search-opensearch-new-frontier/)). Auch kleinere Ingestion-Details summieren sich. OpenSearch 3.8 meldet vierfach schnellere Vektor-Ingestion mit Base64-kodierten Vektoren, und 3.9 brachte den Vektortyp `half_float` sowie 2- und 4-Bit-Skalarquantisierung ([OpenSearch](https://docs.opensearch.org/latest/version-history/)). Die Float-Breite vor dem Indexieren zu halbieren ist oft der günstigste Speichergewinn. Für einen Katalog, der sich täglich statt sekündlich ändert, ist der GPU-Aufbau selten der Engpass; die größeren Ingestion-Kosten entstehen meist beim Erzeugen der Embeddings selbst. Bündeln Sie die Embedding-Aufrufe, überspringen Sie Dokumente, deren eingebetteter Text sich nicht geändert hat, und betten Sie nur beim Modellwechsel alles neu ein. Ein GPU-Indexaufbau wird bei kompletten Neuaufbauten mit zig Millionen Vektoren interessant, weil er das Zeitfenster verkürzt, in dem ein neuer Index vorbereitet wird. ## Die Lizenzgeschichte und was sie für Sie bedeutet Im April 2021 kündigte AWS OpenSearch als Community-Fork von Elasticsearch und Kibana 7.10.2 unter der Apache License 2.0 an ([AWS](https://aws.amazon.com/blogs/opensource/introducing-opensearch/)), nachdem Elastic zu SSPL und einer eigenen Elastic License gewechselt war. Am 29. August 2024 ergänzte Elastic die AGPL v3 als dritte Option neben ELv2 und SSPL ([Elastic](https://www.elastic.co/blog/elasticsearch-is-open-source-again)). OpenSearch bleibt reines Apache-2.0. Ausgangslage Vektor-Setup Hybride Fusion GPU-Aufbau Lizenzfrage Bereits auf Elasticsearch dense\_vector, Standard bbq\_hnsw rrf-Retriever nur Enterprise AGPL, SSPL oder ELv2; DiskBBQ braucht Enterprise Bereits auf OpenSearch knn\_vector, Lucene oder Faiss Normalisierung oder Score-Ranker seit 3.1 verfügbar Apache-2.0 Neuprojekt, Vektoren sind die Hauptlast eigenen Speicher erwägen je nach Speicher je nach Speicher je Speicher prüfen Die praktische Folge steckt in der Funktionsliste, nicht nur im Lizenztext. Mehrere der oben beschriebenen Vektorfunktionen von Elasticsearch, darunter DiskBBQ und GPU-Indexierung, brauchen ein Enterprise-Abo, während die entsprechenden OpenSearch-Funktionen in der Apache-2.0-Distribution enthalten sind. Managed-Angebote der Cloud-Anbieter bringen eigene Bedingungen mit, vergleichen Sie also die Funktion, die Sie wirklich brauchen, in der Edition, die Sie wirklich betreiben würden. **Lizenzen sind eine Produktentscheidung** Einen Suchcluster hinter der eigenen Anwendung zu betreiben ist etwas anderes, als ihn als Dienst anzubieten oder in einem Produkt auszuliefern. Genau in diesen Fällen zählen die Unterschiede zwischen AGPL, SSPL, ELv2 und Apache-2.0, also klären Sie die Frage mit den Lizenzverantwortlichen, bevor Sie auf kostenpflichtige Funktionen bauen. ## Wann Elasticsearch oder OpenSearch der falsche Vektorspeicher ist Ein eigener Vektorspeicher gewinnt, wenn Vektoren die Hauptlast sind und keine Ergänzung zur Textsuche, wenn der Index zu groß ist, um ihn zu einem akzeptablen Preis im Page Cache zu halten, oder wenn Sie Namespaces pro Mandant, sehr hohe Schreibraten oder vektornative Funktionen brauchen, die Suchmaschinen nicht bieten. Er gewinnt auch, wenn im Team niemand überhaupt einen JVM-Suchcluster betreiben will. Dann starten Sie bei den eigenen Optionen wie [pgvector](https://balazscsorba.com/de/blog/pgvector) oder den Vergleichsartikeln oben. Ein späterer Wechsel ist nicht teuer, wenn Sie ihn einplanen. Speichern Sie Embedding-Modell, Version und den eingebetteten Text neben jedem Vektor und schreiben Sie Dokumente über einen einzigen Indexierungsdienst statt von mehreren Stellen aus. Dann bedeutet der Wechsel des Vektorspeichers oder ein zusätzlicher eigener Speicher für eine einzelne Last nur, die Ingestion gegen ein neues Ziel laufen zu lassen, statt die ganze Pipeline neu zu bauen. ## Eine praktische Checkliste 1. Vektorspeicher bei Ihrer Dimensionszahl und Quantisierungsstufe schätzen und mit dem Page Cache der Knoten vergleichen. 2. Filter in die kNN-Klausel setzen, nicht daneben. 3. Mit der Standard-Quantisierung der Version beginnen und Rescoring eingeschaltet lassen. 4. BM25 und Vektoren zuerst per RRF fusionieren, dann wertbasierte Normalisierung testen. 5. Recall bei k auf einer Stichprobe mit exaktem kNN als Referenz messen. 6. Vor dem Design prüfen, welche Funktionen ein kostenpflichtiges Abo brauchen. 7. Nach jedem Minor-Upgrade neu testen, weil sich Standards zwischen Versionen ändern. Wenn Sie Vektorsuche in einem bestehenden Suchcluster ergänzen wollen, mit gemessenem statt vermutetem Recall, sehen Sie sich meine [KI-Engineering-Arbeit](https://balazscsorba.com/de/expertise/ai-engineer) an. ## Quellen 1. [Elastic docs: kNN search](https://www.elastic.co/docs/solutions/search/vector/knn) 2. [Elastic docs: filtered kNN search](https://www.elastic.co/docs/solutions/search/vector/knn/filtered-knn-search) 3. [Elastic docs: dense\_vector field type](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/dense-vector) 4. [Elastic docs: BBQ](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/bbq) 5. [Elastic docs: reciprocal rank fusion](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion) 6. [Elastic docs: GPU vector indexing](https://www.elastic.co/docs/solutions/search/vector/gpu-vector-indexing) 7. [Elastic blog: Elasticsearch is open source again (Aug 2024)](https://www.elastic.co/blog/elasticsearch-is-open-source-again) 8. [OpenSearch docs: methods and engines](https://docs.opensearch.org/latest/mappings/supported-field-types/knn-methods-engines/) 9. [OpenSearch docs: memory-optimized vectors](https://docs.opensearch.org/latest/mappings/supported-field-types/knn-memory-optimized/) 10. [OpenSearch docs: reciprocal rank fusion](https://docs.opensearch.org/latest/vector-search/ai-search/hybrid-search/rrf/) 11. [OpenSearch docs: version history](https://docs.opensearch.org/latest/version-history/) 12. [AWS Open Source blog: introducing OpenSearch (Apr 2021)](https://aws.amazon.com/blogs/opensource/introducing-opensearch/) ## Häufige Fragen Kann man Elasticsearch als Vektordatenbank nutzen? Ja. Das Feld dense\_vector unterstützt standardmäßig approximatives kNN mit HNSW, exaktes kNN für kleine Kandidatenmengen, Filter während der Suche, Quantisierung und hybride Suche mit BM25 per RRF. Für viele Teams, die Elasticsearch ohnehin betreiben, entfällt damit eine separate Vektordatenbank. Was unterscheidet Elasticsearch und OpenSearch bei der Vektorsuche? OpenSearch ist ein Apache-2.0-Fork von Elasticsearch 7.10.2 aus dem Jahr 2021. Beide bieten HNSW-kNN, Quantisierung und RRF, aber die Details unterscheiden sich: Elasticsearch hat BBQ und DiskBBQ, OpenSearch mehrere Engines wie Lucene, Faiss und das DiskANN-artige JVector sowie On-Disk-Kompressionsmodi. Was ist BBQ in Elasticsearch? Better Binary Quantization, eingeführt mit Elasticsearch 8.16 im September 2024, komprimiert jede Vektordimension auf ein Bit, bis zu 32-fach, während die Rohvektoren für das Rescoring auf der Platte bleiben. Seit 9.1 ist es der Standard-Indextyp für Vektoren mit 384 oder mehr Dimensionen. Ist Elasticsearch wieder Open Source? Seit August 2024 bietet Elastic die AGPL v3 als dritte Lizenzoption neben SSPL und Elastic License 2.0 an. OpenSearch bleibt unter Apache-2.0. Was passt, hängt davon ab, wie Sie Ihr Produkt verteilen oder hosten, also klären Sie das mit den Lizenzverantwortlichen in Ihrem Unternehmen. Wann ist eine eigene Vektordatenbank besser als Elasticsearch oder OpenSearch? Wenn Vektoren die Hauptlast sind und keine Ergänzung zur Textsuche, wenn der Index zu groß ist, um ihn bezahlbar im Page Cache zu halten, oder wenn Sie Funktionen wie mandantenfähige Namespaces in sehr großem Maßstab brauchen. Dann kann ein eigener Speicher wie Qdrant, Milvus oder ein Managed Service einfacher und günstiger sein. Geschrieben von Balázs Csorba Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten. [KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about) ## Weitere Artikel - [Embedding-Modell wählen 2026: Leaderboards, Kosten und ein Vergleichstest mit eigenen Daten](https://balazscsorba.com/de/blog/embedding-model-selection-2026) - [Contextual Retrieval und Late Chunking: RAG-Chunks ihren Kontext zurückgeben](https://balazscsorba.com/de/blog/contextual-retrieval-late-chunking) - [Zugriffskontrolle für RAG: berechtigungsbewusstes Retrieval ohne Datenlecks](https://balazscsorba.com/de/blog/rag-access-control-permissions) - [RAG über Produktkataloge: aus PIM-Daten Antworten machen, die halten](https://balazscsorba.com/de/blog/rag-product-catalog-pim-data) ## Klingt nach dem, was du suchst? Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören. [Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)