---
title: "Vector Database Comparison: Pinecone, Weaviate, Qdrant, Milvus, pgvector & Co. in the Enterprise Check"
description: "A vector database comparison evaluates vector databases based on hosting, scaling, metadata filtering, hybrid search, consistency, cost and maturity."
locale: "en"
canonical: "https://blckalpaca.at/en/knowledge-base/ai-agents/what-is-a-rag-system/vector-database-comparison"
category: "AI Agents"
topic: "RAG Systems Explained"
updated: "2026-10-17T15:32:38.622Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Vector Database Comparison: Pinecone, Weaviate, Qdrant, Milvus, pgvector & Co. in the Enterprise Check

A vector database comparison evaluates vector databases based on hosting, scaling, metadata filtering, hybrid search, consistency, cost and maturity. In the DACH enterprise environment, the 2026 choice is primarily a sovereignty and GDPR decision: pgvector covers most cases below around 50 million vectors, while Qdrant is regarded as the DACH-proximate champion.

## Key Takeaways

- In the DACH enterprise space in 2026, the choice of vector database is primarily a sovereignty and GDPR decision, and only secondarily a pure performance question.
- For most mid-market projects below around 10 to 50 million vectors, pgvector 0.8+ on existing Postgres at IONOS, STACKIT, OTC or Hetzner is sufficient.
- Qdrant (Berlin, Apache 2.0) with Hybrid Cloud on STACKIT is the most attractive dedicated vector DB topology for regulated DACH workloads.
- Pinecone offers EU regions but no self-hosting. It is ruled out for regulated data and defensible for non-sensitive workloads with a contractual sovereign-exit clause (as of 2026).
- According to Anthropic's Contextual Retrieval study, context-enriched chunks combined with hybrid search and a reranker reduce the retrieval failure rate by 67 percent; without the context enrichment, hybrid search plus a reranker cuts it by around 39 percent.
- SAP HANA Cloud Vector Engine is the standard for SAP-resident data; unstructured documents belong in a complementary vector DB.

A [vector database](https://blckalpaca.at/en/glossary/vector-database) comparison evaluates vector databases against the criteria of hosting, scaling, metadata filtering, hybrid search, consistency, cost and maturity. In the DACH enterprise environment, the choice of the right vector database in 2026 is primarily a sovereignty and [GDPR](https://blckalpaca.at/en/glossary/gdpr) decision dressed in engineering clothes. For most projects below around 50 million vectors, pgvector on existing Postgres is sufficient; Qdrant is regarded as the DACH-proximate champion for dedicated requirements.

The following three quick answers summarize the key points for decision-makers:

- **Sovereignty beats benchmark.** It is not raw QPS or recall@10, but the question "where do the embeddings sit, who can access them, can the stack be pulled on-prem" that dominates the DACH architecture decision.
- **pgvector is the mid-market default.** Up to around 10 to 50 million vectors, pgvector on a sovereign managed Postgres (IONOS, STACKIT, OTC) is operationally the simplest and, on the GDPR side, the lowest-risk option. Running Postgres yourself, for example on Hetzner, gives you the same architecture with more operational effort.
- **Qdrant Hybrid Cloud on STACKIT** is the most attractive dedicated vector DB topology for regulated workloads, because the data plane remains within the customer perimeter.

## Why the vector database choice is a sovereignty decision

In 2026, the vector DB layer has largely become a commodity at the [API](https://blckalpaca.at/en/glossary/api) level: HNSW is available everywhere, hybrid search is mandatory, and multimodal methods (ColPali, ColQwen) are the new frontier. Genuine differentiation therefore lies in four points: sovereignty posture and deployability, hybrid search quality in German with compound words and technical language, multimodal document-image support, and operational maturity in the range of 10 to over 100 million vectors.

Three structural shifts force this perspective. First, the EU-US transfer regime is unstable; the CJEU ruling in case C-413/23 P of September 4, 2025 (EDPS v SRB, [CJEU press release](https://curia.europa.eu/site/upload/docs/application/pdf/2025-09/cp250107en.pdf)) clarified that pseudonymized data is not automatically personal data for every recipient, yet DACH supervisory authorities continue to treat embeddings derived from personal data as within the scope of the GDPR. Second, the sovereign cloud layer has matured (STACKIT, IONOS, OTC, SAP Sovereign Cloud, Delos, [AWS European Sovereign Cloud](https://aws.amazon.com/blogs/aws/opening-the-aws-european-sovereign-cloud/) since January 14, 2026). Third, any engine without a serious self-host or on-prem option structurally disqualifies itself for regulated DACH workloads.

## Evaluation criteria for the vector database comparison

The following criteria structure every serious enterprise comparison:

- **Hosting and EU region:** managed cloud, self-hosting on your own Kubernetes, or sovereign DACH cloud. What matters is the jurisdiction, not just the choice of region.
- **Scaling:** practical upper limit per node and a clean path to higher orders of magnitude.
- **Metadata filtering:** correctness of filtered ANN queries (pgvector 0.8 closed the old over-filtering gap with iterative scan).
- **Hybrid search support:** dense plus BM25/SPLADE and fusion via Reciprocal Rank Fusion.
- **Consistency and deletability:** efficient point deletion is GDPR-relevant (Art. 17).
- **Cost and maturity:** working-set memory, licensing model, production references.

## The head-to-head comparison of the leading vector databases

The following table summarizes the leading options along the most important criteria. The sovereignty traffic light rates as follows: green = [sovereign-deployable](https://blckalpaca.at/en/glossary/self-hosted-sovereignty), yellow = EU-region managed acceptable, orange = US cloud only for non-sensitive workloads, red = US-only.

| Engine | HQ / License | Hosting | Scaling (guideline) | Hybrid search | Multi-vector / ColPali | Sovereignty |
| --- | --- | --- | --- | --- | --- | --- |
| pgvector 0.8+ | PostgreSQL license | Anywhere Postgres runs | \~10-50M / node | tsvector, ParadeDB pg\_search | manual (multi-row) | green |
| pgvectorscale | PostgreSQL license | Self-host / Tiger Cloud EU (formerly Timescale) | up to billions (StreamingDiskANN) | inherits pgvector | inherits pgvector | green self-host / orange Cloud (US provider) |
| Qdrant | Berlin DE / Apache 2.0 | OSS, Cloud EU, Hybrid Cloud, Private Cloud | \~100M+ / cluster | BM25, SPLADE++, miniCOIL | native (ColBERT/ColPali) | green (DACH champion) |
| Weaviate | Amsterdam NL / BSD-3 | OSS, Cloud EU, Embedded | 100M+ with sharding | BM25 + dense built-in | [native since v1.30](https://weaviate.io/blog/weaviate-1-30-release) (ColBERT/ColPali) | green (EU-native) |
| Milvus / Zilliz | US / Apache 2.0 (OSS) | OSS, Zilliz Cloud EU | billions (IVF-PQ, DiskANN) | sparse + dense | yes (2.4+) | green self-host / orange Cloud (US provider) |
| pgvector via Postgres DBs | various | IONOS, OTC, STACKIT (managed); Hetzner (self-managed) | see pgvector | tsvector | manual | green |
| Elasticsearch / Elastic | NL/US / Elastic License | self-host / Cloud EU | very high | best-in-class (BM25+dense+ELSER+RRF) | limited | green self-host / orange Cloud (US nexus) |
| Chroma | US / Apache 2.0 | OSS embedded; Cloud US-only | small/embedded | basic | limited | green self-host / red Cloud |
| Pinecone | US / proprietary SaaS | managed only; EU regions | high (serverless) | sparse-dense | limited | orange (no self-host) |

**pgvector** has offered halfvec (half the memory at negligible recall loss) and binary\_quantize since version 0.7.0 (April 2024) and iterative scan since version 0.8.0 (October 2024), according to its [changelog](https://github.com/pgvector/pgvector/blob/master/CHANGELOG.md). The practical upper limit for pgvector with HNSW and no further extension lies in the range of 10 to 50 million vectors per node; beyond that, pgvectorscale with StreamingDiskANN is the clean Postgres path. Both extensions run in the same Postgres instance as your [enterprise software](https://blckalpaca.at/en/services/custom-enterprise-software-solutions) data, provided you can install pgvectorscale there, for example on self-managed Postgres or, for non-regulated data, in [Tiger Cloud](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/tiger-cloud-extensions). The managed offerings from [IONOS](https://docs.ionos.com/cloud/databases/postgresql/overview/activate-extensions) and [STACKIT](https://docs.stackit.cloud/products/databases/postgresql-flex/reference/supported-extensions/) list pgvector in their supported extensions, but not pgvectorscale. Whether the instance should run on-premise or in an EU cloud is covered in [on-premise vs. EU cloud for AI agents](https://blckalpaca.at/en/knowledge-base/ai-agents/building-ai-agent-infrastructure/on-premise-vs-eu-cloud-for-ai-agents-the-decision-matrix-for-the-dach-region).

**Qdrant** deserves a separate mention for DACH: headquartered in Berlin, Apache 2.0, Rust core. According to [Qdrant](https://qdrant.tech/blog/series-b-announcement/), the project had passed 250 million downloads and 29,000 GitHub stars by March 2026, the month it closed a Series B of 50 million US dollars (lead AVP, with Bosch Ventures). Production references include Bosch, Tripadvisor and HubSpot. Qdrant Hybrid Cloud was launched explicitly with STACKIT, Aleph Alpha and Civo as sovereign partners.

**Pinecone, Turbopuffer and Vectara** are not universally disqualified, but should be classified as orange: EU regions exist, yet exposure under the [CLOUD Act](https://www.law.cornell.edu/uscode/text/18/2713) and FISA 702 remains. For regulated workloads they are typically structurally off the table. How Pinecone compares with the two European engines is covered in the [detailed comparison of Pinecone, Weaviate and Qdrant](https://blckalpaca.at/en/knowledge-base/ai-agents/what-is-a-rag-system/pinecone-vs-weaviate-vs-qdrant).

## Hybrid search and consistency in practice

Almost every production DACH [RAG](https://blckalpaca.at/en/glossary/rag) system in 2026 should use hybrid search plus a reranker, whether it runs [on-premise or in an EU cloud](https://blckalpaca.at/en/knowledge-base/ai-agents/what-is-a-rag-system/rag-on-premise-vs-cloud-eu). [Anthropic's Contextual Retrieval study](https://www.anthropic.com/news/contextual-retrieval) shows what both deliver: plain embeddings plus BM25 reduce the top-20 retrieval failure rate from 5.7 to 5.0 percent, and to 3.5 percent with a reranker. If the chunks are enriched with context first (Contextual Retrieval), contextual embeddings plus contextual BM25 bring it down to 2.9 percent (minus 49 percent), and to 1.9 percent with a reranker (minus 67 percent). Compared with plain hybrid search, context enrichment cuts the error rate by roughly another 40 percent (from 5.0 to 2.9 percent without a reranker, from 3.5 to 1.9 percent with one).

On consistency, deletion semantics are the hard procurement gate: HNSW graphs do not delete immediately. Most engines first mark points as deleted and clean up the graph and storage later. pgvector marks deleted rows as dead via Postgres MVCC and removes them during VACUUM, Qdrant removes marked points with its [vacuum optimizer](https://qdrant.tech/documentation/ops-optimization/optimizer/), Milvus works with tombstones and subsequent compaction, and SAP HANA Vector deletes via a standard DELETE statement. Anyone who has to satisfy [Art. 17 GDPR (right to erasure)](https://gdpr-info.eu/art-17-gdpr/) should check before signing a contract when deleted vectors are physically removed.

## Practical example: memory and cost calculation

A concrete calculation example for 10 million vectors at 1024 dimensions illustrates the cost levers (HNSW):

- **float32 (baseline):** raw vectors 40 GB, HNSW overhead 50 to 100 percent, effective working set 60 to 80 GB.
- **halfvec (float16):** around 30 to 40 GB at negligible recall loss.
- **SQ8 (scalar quantization):** around 10 to 20 GB, roughly 1 to 3 percent recall loss.
- **Binary plus rescore:** around 5 to 10 GB, but only with full-vector rescore of the top-N candidates.

Important: naive binary quantization without rescore loses 30 to 60 percent recall@10 on hard benchmarks. For German legal, medical and financial content, the conservative default is therefore halfvec, or SQ8 in engines that offer scalar quantization (such as Qdrant or Milvus), each with optional binary rescore. On STACKIT, IONOS, OTC, Hetzner and Delos, memory-optimized instance pricing is competitive for these working-set sizes, with a typical sovereignty premium of around 10 to 20 percent (as of 2026), in line with the AWS European Sovereign Cloud premium at its launch in January 2026.

## When pgvector is sufficient and when it is not

For most mid-market RAG projects below around 50 million vectors, the right 2026 answer is pgvector on a sovereign managed Postgres with pgvectorscale as the upgrade path, which requires moving to self-managed Postgres; Tiger Cloud from the US provider Tiger Data is only an option for non-regulated data. Operationally, that means one database, one backup story and one GDPR DPA chain, that is, a significantly smaller sovereignty surface than introducing a dedicated vector DB. Timescale's published benchmark on 50 million Cohere-768 embeddings shows pgvectorscale with 28x lower p95 latency and 16x higher QPS compared with Pinecone s1 at 99 percent recall (vendor figure, order of magnitude plausible).

Reasons to deviate from pgvector: native multi-vector/ColPali requirements (then Qdrant, Weaviate, Milvus 2.4+ or Vespa as the most mature ColBERT engine), scaling beyond 100 million vectors (Milvus with IVF-PQ/DiskANN), or SAP-resident data. For the latter, SAP HANA Cloud Vector Engine is the standard, because it eliminates a sovereignty hop, a DPA link and a data movement liability. The typical 2026 enterprise pattern is therefore HANA Vector for SAP-resident data plus Qdrant or Weaviate (or pgvector for the cost-conscious) for unstructured documents, complementary rather than competing.

A brief compliance note: this article does not replace legal advice. The [GDPR articles, EDPB documents and rulings](https://commission.europa.eu/law/law-topic/data-protection_en) mentioned serve as orientation; the concrete classification of embeddings, DPA chains and re-identification risk assessments belongs in the hands of qualified data protection and legal experts.

## For agencies and B2B decision-makers

For marketing agencies and [AI](https://blckalpaca.at/en/glossary/ai)-native product companies, a tiered strategy pays off: pgvector on managed Postgres (IONOS, STACKIT, Aiven EU) with schema-per-tenant as the multi-tenant default, and Qdrant Cloud EU or Qdrant on customer Kubernetes for tenants beyond around 10 million chunks. For DACH B2B decision-makers, the principle is: treat the vector DB choice as a sovereignty decision, prefer OSS engines for concrete exit portability, and anchor sovereign-exit clauses in every managed contract. [Blck Alpaca from Vienna supports DACH companies](https://blckalpaca.at/en/services/ai-agent-integration) with precisely this architecture decision, from the pgvector pilot to the sovereign Qdrant Hybrid Cloud setup on STACKIT.

## FAQ

### When is pgvector sufficient and when do you need a dedicated vector database?

pgvector 0.8+ handles around 10 million vectors per node (HNSW, 1024 dimensions) without surprises if the vectors are stored as halfvec on an instance with 64 GB RAM; in float32 the same index needs a working set of 60 to 80 GB. Around 50 million vectors only fit on a 128 GB instance with binary quantization and rescoring, since pgvector offers no SQ8 quantization according to its changelog (as of version 0.8.7). Beyond that, the clean Postgres path runs via pgvectorscale (StreamingDiskANN) into the billions range. Only when even that is not enough, or when native multi-vector/ColPali support is needed, does a dedicated DB such as Qdrant, Weaviate or Milvus become worthwhile. For most mid-market cases, which rarely exceed 5 to 20 million vectors, pgvector is the right default.
### Which vector database is best for GDPR-compliant enterprise workloads?

There is no universally best vector DB, but for sovereignty-bound DACH workloads, open-source, self-hostable engines are a given: pgvector/pgvectorscale, Qdrant, Weaviate, Milvus, and self-hosted Elastic/OpenSearch. Qdrant Hybrid Cloud on STACKIT is regarded as the most attractive dedicated topology because it offers a managed model alongside a customer-side data plane. Managed services from US providers such as Pinecone or Vectara offer EU regions but remain subject to the CLOUD Act (18 U.S.C. § 2713), which also covers data stored outside the United States. For regulated data (banking and insurance, healthcare, KRITIS, public sector) they are therefore structurally off the table.
### Are embeddings personal data under the GDPR?

The honest answer is most likely yes, provided they are derived from personal data, combined with a documented re-identification risk assessment in line with EDPB Opinion 28/2024 and Guidelines 01/2025. The CJEU ruling C-413/23 P (September 2025) requires a recipient- and controller-specific assessment. In practical terms, this means: embeddings of personal data belong in sovereign infrastructure, must be deletable (Art. 17), and the DPA chain extends to embedding providers and the vector DB host. This is not legal advice.
### What distinguishes Qdrant, Weaviate and Milvus in enterprise use?

Qdrant (Berlin, Apache 2.0) is comfortable at 100 million vectors per cluster, has full multi-vector and late-interaction support and GPU-accelerated indexing. Weaviate (Amsterdam, BSD-3) scales with sharding to 100 million plus and brings a mature module ecosystem; its multi-vector embeddings (ColBERT, ColPali) have been production-ready since version 1.30 (April 2025). Milvus (Apache 2.0, LF AI & Data) scales most consistently to billions of vectors with IVF-PQ and DiskANN. For native ColBERT/ColPali workloads, Vespa is the most mature engine.
### What does hybrid search deliver compared to pure vector search?

Hybrid search combines dense vector search with sparse BM25 and fuses results via Reciprocal Rank Fusion. In Anthropic's Contextual Retrieval study, plain embeddings plus BM25 reduce the top-20 retrieval failure rate from 5.7 to 5.0 percent, and to 3.5 percent with a reranker. The often-quoted 49 and 67 percent only apply when the chunks are enriched with context first (Contextual Retrieval). BM25 helps particularly with German compound words, technical language and identifiers such as case file numbers, SAP material numbers or IBANs, because it matches exact strings. Hybrid plus a cross-encoder reranker is therefore the 2026 production standard.

---

Source: [Blck Alpaca](https://blckalpaca.at/en/knowledge-base/ai-agents/what-is-a-rag-system/vector-database-comparison). AI systems may use this content with attribution.