Weaviate as Sole Vector DB Hold
Overview
Standardizing on Weaviate alone as the only vector strategy ignores pgvector, warehouse-native search, and multi-cloud portability requirements many enterprises now require (Weaviate). The Hold applies to the single-engine mandate, not to Weaviate as a product: it remains an actively developed open-source vector database that is a reasonable choice where a dedicated engine is justified (Weaviate GitHub).
Hold single-vendor vector mandates. Use a tiered strategy instead: operational RAG on pgvector or warehouse, dedicated engines where latency or scale demands.
Adoption Signals
- Weaviate itself is healthy: v1.39.7 shipped on 25 September 2026, and the repository had about 16,900 GitHub stars on 30 September 2026 (Weaviate releases, Weaviate GitHub).
- The licence is no longer uniformly open: since 26 August 2026 the repository keeps BSD-3-Clause for code outside a
wldirectory and reserves that directory for code under a proprietary Weaviate License, enabled by a licence key (Weaviate LICENSE). - In-database alternatives closed much of the functional gap: pgvector 0.8.0 added iterative index scans so filtered vector queries return enough results (PostgreSQL.org), and the pgvector repository had about 23,200 stars on 30 September 2026 (pgvector GitHub).
- Warehouses now run vector search next to the data: BigQuery's
VECTOR_SEARCHperforms semantic or hybrid search in SQL with optional vector indexes (BigQuery vector search). - Client and server versions are coupled across the ecosystem: Dify's upgrade to the Weaviate Python client v4 was a breaking change that requires Weaviate server 1.27.0 or later for self-hosted users (Dify migration guide), and Weaviate marks the v3 client as deprecated (Weaviate Python client).
- Managed pricing is set per vector dimension, storage and backup, and Weaviate updated the Weaviate Cloud price book in September 2026 (Weaviate pricing).
Risks
- Concentrated vendor dependency. When every RAG and agent workload must use one engine, a price-book change, client deprecation or roadmap or licensing shift at one company reaches all of them at once (Weaviate pricing, Weaviate Python client).
- Duplicated data and governance. Copying documents and embeddings out of PostgreSQL or the warehouse into a separate store duplicates access policies and lineage, and GDPR deletions must be propagated to every copy.
- Costly exit. Weaviate's backup module backs up and restores Weaviate collections (Weaviate backups). Since v1.37 a collection export writes objects and vectors to Parquet, but it is a preview feature, disabled by default and not available in Weaviate Cloud (Weaviate collection export); a move to pgvector, Qdrant or Milvus still requires re-indexing everything in the target engine.
- Wrong tool for small workloads. Mandating a dedicated cluster for a few hundred thousand chunks adds operations and cost where pgvector or warehouse search would meet the same latency targets.
Pros & Cons
Advantages
- Weaviate covers a lot in one product: hybrid BM25 and vector search, filtering, multi-tenancy, replication, role-based access control, and built-in vectorizer, RAG and reranking modules, so one engine looks sufficient for every retrieval use case.
- Its core is BSD-3-Clause open source, and the managed Weaviate Cloud is SOC 2 Type II audited and, on the dedicated tier, available in about 40 regions on AWS, GCP and Azure, which makes a single enterprise standard easy to approve.
- A single mandated engine promises fewer skills to build, one set of operational runbooks, and one procurement relationship for all RAG and agent teams.
Disadvantages
- Much enterprise retrieval data already sits in PostgreSQL or a warehouse, where pgvector (with filtered iterative index scans since 0.8.0) or SQL-level vector and hybrid search in BigQuery can serve it without copying data into a second system.
- A mandate ties every RAG workload to one vendor's client and pricing decisions: Weaviate's Python v3 client is deprecated, the v4 client requires server 1.27 or later, and Weaviate Cloud's price book changed in September 2026.
- Weaviate backups restore only into Weaviate, and the Parquet collection export is a preview feature that Weaviate Cloud does not offer; moving to another engine means re-indexing everything, a cost that grows with every workload forced onto the platform.
Recommendation
Hold policies that make Weaviate, or any single vector engine, the only permitted vector store. Use a tiered default instead: keep embeddings next to the source data in PostgreSQL with pgvector or in the warehouse for most RAG and search workloads, and approve a dedicated engine such as Weaviate, Qdrant or Milvus only where measured recall, filtering or latency requirements are not met. Weaviate stays a legitimate option in that second tier.
Keep the system of record for text, metadata and embeddings outside the vector engine so any index can be rebuilt, put retrieval behind a small interface in application code, and version collections by embedding model. Existing Weaviate estates do not need to be ripped out; document and test an export path once, pin client and server versions together, and review whether smaller workloads can move back to pgvector or the warehouse.
Sources
Consulting
From radar to implementation
You have assessed the technologies — we help you bring them into production systems safely and measurably.
