TL;DR
- The vector database market has consolidated. Seven options account for most enterprise deployments in Asia.
- For mid-market enterprises, pgvector (PostgreSQL extension) is the strongest default. Specialised vector stores justify themselves only above 50M vectors or for specific feature needs.
- The choice should be driven by your existing data stack, not by benchmarks.
Why now
The vector database market has matured. The 30+ options of 2023 have consolidated to roughly 10 production-grade choices. Pricing has stabilised. Operational patterns are documented. Procurement teams now have enough comparable data to make informed decisions.
For mid-market Asian enterprises building RAG systems, the question is no longer "which vector database is technically best" (the differences are small for most workloads) but "which fits our existing stack, our scale, and our team's operational capacity." This article compares seven options through that lens.
The seven options
1. pgvector (PostgreSQL extension). A vector type and similarity search built into PostgreSQL.
2. Pinecone. Managed vector database, hosted only, designed for scale.
3. Weaviate. Open-source vector database with built-in modules; managed cloud option available.
4. Qdrant. Open-source vector database; cloud option available; strong on filtering.
5. Milvus / Zilliz Cloud. Open-source vector database designed for very large scale; Zilliz is the managed offering.
6. OpenSearch with k-NN. Elastic-fork search engine with vector capabilities; used where keyword and vector search must combine.
7. Vertex AI Vector Search. Google Cloud's managed vector search; tight integration with the rest of Vertex AI.
Several other credible options exist (Chroma for small-scale, MongoDB Atlas Vector Search, Azure AI Search). The seven above cover most production mid-market deployments in Asia in 2025-2026.
How to think about the choice
Three lenses matter.
Lens 1: Existing data stack. If you already run PostgreSQL, pgvector should be the default unless ruled out. If you run Elasticsearch, OpenSearch is natural. If you are deep in Google Cloud, Vertex AI Vector Search reduces friction. Buying a new database technology to host vectors creates operational overhead that is rarely justified.
Lens 2: Scale. Most mid-market enterprise RAG deployments operate on 100,000 to 10 million vectors. All seven options handle this comfortably. Above 100 million vectors the choice narrows: Milvus, Pinecone, Vertex AI Vector Search, and Weaviate are the strongest at very large scale.
Lens 3: Operational capacity. A managed service (Pinecone, Zilliz, Vertex AI) removes operational burden at higher unit cost. A self-hosted open-source option (pgvector, Qdrant, Weaviate, Milvus, OpenSearch) lowers unit cost but adds engineering responsibility.
Profile: pgvector
Best for. Mid-market enterprises already running PostgreSQL. Teams who value operational simplicity over absolute performance.
Strengths. No new database to operate. Transactional with the rest of the data. Mature ecosystem (backups, monitoring, replication). Free.
Limitations. Performance ceiling lower than specialised stores at very large scale. Filter performance can be a tuning challenge. HNSW index becomes large at high vector counts.
Operational profile. If your DBA team operates PostgreSQL well, pgvector is a small extension. Index choice (HNSW vs IVFFlat) and tuning are the main learning curves.
Cost shape. Just your existing PostgreSQL infrastructure. Storage and compute scale with the index size and query load.
When to choose. PostgreSQL is already in use, vector count is below 50 million, and the team prefers fewer moving parts.
Profile: Pinecone
Best for. Teams that want a fully managed vector database with predictable scaling.
Strengths. Zero operational burden. Fast to start. Strong on consistent p99 latency above 100M vectors. Mature SDK and tooling.
Limitations. Hosted-only. Per-vector pricing can be expensive at large scale. Vendor lock-in. Limited region availability in Asia (Singapore is well-served; other markets are less so).
Operational profile. SaaS. Setup in minutes. The ongoing operational work is index design and capacity management through the API.
Cost shape. Per-pod or per-namespace pricing depending on tier. Typical mid-market deployment costs US$300-US$2,500 per month.
When to choose. Strong preference for managed services. Single-region or Singapore-centric workloads.
Profile: Weaviate
Best for. Teams that value open-source flexibility with a strong managed cloud option.
Strengths. Open-source with optional managed cloud. Built-in modules for embeddings (avoid embedding-service round-trips). Strong on hybrid search. Active community.
Limitations. Self-hosted operations require engineering investment. Schema design has a learning curve.
Operational profile. Self-hosted on Kubernetes is common. Managed cloud removes burden at moderate cost.
Cost shape. Self-hosted: infrastructure cost only (typically US$200-US$1,000 per month for mid-size deployments). Managed cloud: per-cluster pricing.
When to choose. Open-source preference, want optionality between self-hosted and managed, value built-in module ecosystem.
Profile: Qdrant
Best for. Teams that need strong filtering and metadata performance.
Strengths. Open-source. Excellent filtering (vector + metadata) performance. Rust-based, efficient. Strong cloud option.
Limitations. Smaller ecosystem than Weaviate or Milvus. Newer, less battle-tested at very large scale.
Operational profile. Self-hosted is straightforward; managed cloud is mature.
Cost shape. Self-hosted: low. Cloud: competitive with Pinecone, often cheaper above 50M vectors.
When to choose. Filtering performance matters (e.g., per-tenant isolation, complex metadata queries), open-source preference.
Profile: Milvus / Zilliz Cloud
Best for. Teams operating at very large scale (100M+ vectors).
Strengths. Designed for scale. Strong distributed architecture. Mature in production at very high vector counts. Active community and managed offering.
Limitations. More complex to operate self-hosted. Overkill for smaller deployments.
Operational profile. Self-hosted on Kubernetes is involved. Zilliz Cloud is the managed alternative.
Cost shape. Self-hosted: infrastructure cost; significant operational engineering. Zilliz Cloud: per-collection pricing.
When to choose. Vector counts above 100 million, scaling is a first-class concern.
Profile: OpenSearch with k-NN
Best for. Teams that already run Elasticsearch or OpenSearch and need to combine keyword and vector search.
Strengths. Mature search engine. Strong hybrid (keyword + vector) capabilities. Already familiar to most engineering teams.
Limitations. Not purpose-built for vectors. Performance and cost less competitive than specialised stores at large vector counts.
Operational profile. If you already operate OpenSearch, adding k-NN is incremental. Otherwise, OpenSearch is a significant new system to operate.
Cost shape. Existing OpenSearch infrastructure plus the additional storage and compute for vector indices.
When to choose. Existing OpenSearch deployment, hybrid search is essential, vector counts moderate.
Profile: Vertex AI Vector Search
Best for. Teams deep in Google Cloud who want native integration.
Strengths. Tight integration with Vertex AI services. Managed, Google-grade infrastructure. Good Asia region availability (Tokyo, Singapore, Seoul).
Limitations. Google Cloud lock-in. Pricing can be opaque. Less SDK ecosystem than the open-source options.
Operational profile. SaaS within Google Cloud. Setup involves Vertex AI configuration.
Cost shape. Storage plus per-query pricing. Often cost-effective for moderate workloads.
When to choose. Google Cloud is the strategic platform, Vertex AI is in use, regional availability matters.
Implementation playbook
How to choose for a new RAG deployment.
- Inventory your existing data stack. PostgreSQL, Elasticsearch, Google Cloud, Snowflake, etc.
- Estimate vector count at year-1 and year-3. Most underestimate growth. Multiply your estimate by 3.
- Identify must-have features. Hybrid search, multi-tenant isolation, on-prem hosting, etc.
- Identify operational capacity. Self-hosted vector store is 0.2-0.4 FTE of engineering effort to operate well.
- Apply the three lenses. Stack fit, scale fit, operational fit. Pick the option that scores best on all three.
- Run a proof of concept. Two weeks. Real data subset, real query patterns. Compare latency, recall, and cost.
- Document the choice. Why you chose it, what the alternatives were, what would trigger a change.
What the benchmarks miss
Public vector database benchmarks measure narrow performance dimensions on synthetic workloads. Real production performance is shaped by:
- Embedding model choice (often a bigger driver of recall than store choice)
- Index parameters (HNSW M and ef, IVF nlist and nprobe)
- Filter selectivity in your real queries
- Update patterns (frequent re-indexing changes performance characteristics)
- Cache hit rates in real query distributions
Benchmarks are useful for elimination, not selection. Use them to rule out clearly unsuitable options. Pick from the remaining shortlist based on the three lenses.
Counter-arguments
"We need the highest-performance option." Performance differences between the seven options are small at mid-market scale. Operational fit dominates total cost.
"Open-source will always be cheaper." Per-month infrastructure cost, often yes. Total cost including engineering operation, often not. McKinsey's Cloud Native AI in Asia 2025 found that mid-market enterprises self-hosting vector stores had 1.4x the total cost of those using managed services, once engineering time was counted.[^1]
"We will switch later if needed." Switching vector stores in production is non-trivial. Re-embedding the corpus, validating quality regression, and managing dual-write windows is a multi-month project. Better to choose well in advance.
Bottom line
For most mid-market Asian enterprises the right vector database in 2026 is the one that fits their existing data stack and operational capacity. pgvector is the strongest default for PostgreSQL shops. Specialised vector stores justify themselves above 50M vectors, for specific feature needs, or where a managed service is strongly preferred.
Run the three-lens analysis. Pick the option that scores well on all three. Avoid optimising for a benchmark that does not match your real workload.
Next read
- RAG vs Fine-Tuning vs Prompting: Which Pattern Fits Your Use Case?
- Building an Internal AI Platform: Reference Architecture for 200-1,000 Person Companies
By Sara Itoh, Senior Advisor, AI Operations.
[^1]: McKinsey & Company, Cloud Native AI in Asia 2025, July 2025, p. 41.
Where this applies
How AIMenta turns these ideas into engagements — explore the relevant service lines, industries, and markets.
Beyond this insight
Cross-reference our practice depth.
If this article matches your stage of thinking, the underlying capabilities ship across all six pillars, ten verticals, and nine Asian markets.