Weaviate as Sole Vector DB Hold
Überblick
Weaviate als einzige Vector-Strategie ignoriert pgvector, Warehouse-native Search und Multi-Cloud-Portabilität, die viele Enterprises heute brauchen (Weaviate). Das Hold gilt dem Mandat für eine einzige Engine, nicht Weaviate als Produkt: Weaviate ist eine aktiv entwickelte Open-Source-Vector-Database und eine vernünftige Wahl, wo eine dedizierte Engine gerechtfertigt ist (Weaviate GitHub).
Hold Single-Vendor-Vector-Mandate. Stattdessen eine gestaffelte Strategie: operatives RAG auf pgvector oder Warehouse, dedizierte Engines bei Latenz- oder Skalierungsbedarf.
Adoptionssignale
- Weaviate selbst ist gesund: v1.39.7 erschien am 25. September 2026, und das Repository hatte am 30. September 2026 rund 16.900 GitHub-Stars (Weaviate Releases, Weaviate GitHub).
- Die Lizenz ist nicht mehr einheitlich offen: Seit dem 26. August 2026 steht Code außerhalb eines
wl-Verzeichnisses weiter unter BSD-3-Clause, während dieses Verzeichnis für Code unter einer proprietären Weaviate License reserviert ist, die per Lizenzschlüssel aktiviert wird (Weaviate LICENSE). - Datenbankinterne Alternativen haben einen Großteil der funktionalen Lücke geschlossen: pgvector 0.8.0 brachte iterative Index-Scans, damit gefilterte Vektorabfragen genügend Ergebnisse liefern (PostgreSQL.org); das pgvector-Repository hatte am 30. September 2026 rund 23.200 Stars (pgvector GitHub).
- Warehouses führen Vektorsuche direkt neben den Daten aus:
VECTOR_SEARCHin BigQuery erledigt semantische oder hybride Suche in SQL, optional mit Vektorindizes (BigQuery Vector Search). - Client- und Server-Versionen sind im Ökosystem gekoppelt: Difys Umstieg auf den Weaviate-Python-Client v4 war ein Breaking Change, der für Self-Hosted-Nutzer Weaviate-Server 1.27.0 oder neuer voraussetzt (Dify Migration Guide), und Weaviate kennzeichnet den v3-Client als deprecated (Weaviate Python Client).
- Das Managed-Pricing richtet sich nach Vektordimensionen, Storage und Backups, und Weaviate hat das Preisbuch von Weaviate Cloud im September 2026 aktualisiert (Weaviate Pricing).
Risiken
- Gebündelte Anbieterabhängigkeit. Müssen alle RAG- und Agent-Workloads dieselbe Engine nutzen, trifft eine Änderung des Preisbuchs, eine Client-Deprecation, ein Lizenz- oder ein Roadmap-Wechsel bei einem Unternehmen alle gleichzeitig (Weaviate Pricing, Weaviate Python Client).
- Doppelte Daten und Governance. Werden Dokumente und Embeddings aus PostgreSQL oder dem Warehouse in einen separaten Store kopiert, verdoppeln sich Zugriffsrichtlinien und Lineage, und DSGVO-Löschungen müssen in jede Kopie propagiert werden.
- Teurer Ausstieg. Das Backup-Modul von Weaviate sichert und restauriert Weaviate-Collections (Weaviate Backups). Seit v1.37 schreibt ein Collection-Export Objekte und Vektoren nach Parquet, allerdings als Preview-Feature, standardmäßig deaktiviert und nicht in Weaviate Cloud verfügbar (Weaviate Collection Export); ein Wechsel zu pgvector, Qdrant oder Milvus erfordert trotzdem ein vollständiges neues Indexing in der Ziel-Engine.
- Falsches Werkzeug für kleine Workloads. Ein vorgeschriebener dedizierter Cluster für einige hunderttausend Chunks bringt Betriebsaufwand und Kosten, wo pgvector oder Warehouse-Suche dieselben Latenzziele erreichen würden.
Vorteile & Nachteile
Vorteile
- Weaviate deckt viel in einem Produkt ab: hybride BM25- und Vektorsuche, Filtering, Multi-Tenancy, Replikation, rollenbasierte Zugriffskontrolle sowie eingebaute Vectorizer-, RAG- und Reranking-Module. Eine einzige Engine wirkt deshalb für jeden Retrieval-Use-Case ausreichend.
- Der Kern von Weaviate ist Open Source unter BSD-3-Clause, die Managed Weaviate Cloud ist nach SOC 2 Type II auditiert und im Dedicated-Tier in rund 40 Regionen auf AWS, GCP und Azure verfügbar; ein einheitlicher Enterprise-Standard lässt sich so leicht genehmigen.
- Eine einzige vorgeschriebene Engine verspricht weniger aufzubauendes Know-how, ein gemeinsames Set an Runbooks und eine Einkaufsbeziehung für alle RAG- und Agent-Teams.
Nachteile
- Viele Retrieval-Daten im Unternehmen liegen bereits in PostgreSQL oder einem Warehouse, wo pgvector (seit 0.8.0 mit iterativen Index-Scans für gefilterte Abfragen) oder Vektor- und Hybrid-Suche per SQL in BigQuery sie bedienen können, ohne Daten in ein zweites System zu kopieren.
- Ein Mandat bindet jede RAG-Workload an Client- und Preisentscheidungen eines Anbieters: Weaviates Python-Client v3 ist deprecated, der v4-Client verlangt Server 1.27 oder neuer, und das Preisbuch von Weaviate Cloud wurde im September 2026 geändert.
- Weaviate-Backups lassen sich nur in Weaviate wiederherstellen, und der Parquet-Export von Collections ist ein Preview-Feature, das Weaviate Cloud nicht anbietet; der Wechsel zu einer anderen Engine bedeutet vollständiges Neu-Indexieren – ein Aufwand, der mit jeder auf die Plattform gezwungenen Workload wächst.
Empfehlung
Hold für Richtlinien, die Weaviate oder irgendeine einzelne Vector-Engine zum einzig zulässigen Vector Store machen. Besser ist ein gestaffelter Standard: Embeddings für die meisten RAG- und Such-Workloads neben den Quelldaten in PostgreSQL mit pgvector oder im Warehouse halten und eine dedizierte Engine wie Weaviate, Qdrant oder Milvus nur dort freigeben, wo gemessene Anforderungen an Recall, Filtering oder Latenz nicht erfüllt werden. Weaviate bleibt in dieser zweiten Stufe eine legitime Option.
Das führende System für Text, Metadaten und Embeddings sollte außerhalb der Vector-Engine liegen, damit sich jeder Index neu aufbauen lässt; Retrieval gehört hinter eine schmale Schnittstelle im Anwendungscode, und Collections werden nach Embedding-Modell versioniert. Bestehende Weaviate-Umgebungen müssen nicht herausgerissen werden: einen Exportpfad einmal dokumentieren und testen, Client- und Server-Versionen gemeinsam pinnen und prüfen, ob kleinere Workloads zurück zu pgvector oder ins Warehouse wandern können.
Quellen
Beratung
Vom Radar zur Umsetzung
Du hast Technologien bewertet — wir helfen dir, sie sicher und messbar in produktive Systeme zu bringen.
