The category that finally grew up

Two years ago, "which vector database should we use?" was a religious question. Every startup had a favorite, every vendor claimed to be fastest, and the answer usually came down to whichever demo the CTO had seen last.

That era is over. In 2026 the vector database market has consolidated around a small set of serious contenders, real production benchmarks exist, and the trade-offs are finally clear. We've deployed and migrated between most of them across enterprise engagements in the past twelve months. This is the honest scorecard, not the vendor pitch.

If you're picking a vector database in 2026, read this. Then run your own benchmark on your own data. Do both.

What actually changed

The vector database market of 2024 was defined by pure similarity search. You had embeddings, you had queries, you wanted the top-K nearest neighbors. Everyone competed on speed and price.

By 2026, that job is table stakes. What matters now is everything around it:

• Hybrid search — vector plus keyword plus structured filter, all in one query.
• Metadata filtering at scale — "top 10 similar documents, but only from tenant X, and only marked public, and updated in the last 30 days."
• Multi-tenancy — safely partitioning millions of tenants without spinning up millions of clusters.
• Real-time indexing — new documents queryable within seconds, not minutes.
• Cost predictability — knowing what a million queries per day actually costs.
• On-prem or VPC deployment — for regulated industries (finance, health, KSA/UAE government).

The vendors have all iterated toward this. The differences are now in the details.

The nine we evaluated

Not all are direct competitors, but all are worth knowing.

• Pinecone — the dominant managed vendor, mature and expensive.
• Weaviate — open-source with strong hybrid search and managed cloud.
• Qdrant — Rust-based, excellent performance, growing enterprise story.
• Milvus / Zilliz — mature Chinese-origin project, large-scale reference deployments.
• LanceDB — file-based, embedded, gaining serious adoption.
• pgvector — a Postgres extension. Not a "vector database" per se; a Postgres that also does vectors.
• Turso vector — SQLite-based, ties into the database-per-agent pattern.
• Vespa — the veteran, unmatched at scale, higher operational overhead.
• Redis vector search — for teams already on Redis; not a full RAG solution, but often good enough.

We tested each against four representative workloads.

The four workloads

Workload 1 — Enterprise RAG. ~500K documents, 1024-dim embeddings, tenant-filtered queries, mixed hybrid (vector + BM25 + metadata). This is the "internal knowledge base" archetype.

Workload 2 — E-commerce semantic search. ~5M product embeddings, faceted metadata (category, price band, stock), millisecond p95 latency required, updates in near-real-time.

Workload 3 — Multi-tenant SaaS. ~10K tenants, each with 5K-50K documents. Query patterns bursty. Strict isolation. Cost must scale sub-linearly with tenant count.

Workload 4 — Long-tail agent memory. Millions of short embeddings (agent conversations, tool logs), each queried rarely. Storage cost dominates. Retrieval is best-effort.

Different workloads reward different vendors. That's the whole point.

The scorecard

Here's how each database performed on the dimensions that matter. Ratings are calibrated to our production experience — your mileage will vary.

| | Enterprise RAG | E-commerce | Multi-tenant | Agent memory | Operational cost | |---|---|---|---|---|---| | Pinecone | Excellent | Good | Excellent | Expensive | High | | Weaviate | Excellent | Very good | Very good | Moderate | Medium | | Qdrant | Very good | Excellent | Very good | Moderate | Medium | | Milvus | Very good | Excellent | Very good | Good | Medium-high | | LanceDB | Good | Fair | Good | Excellent | Low | | pgvector | Very good | Good | Excellent | Very good | Very low (if already on Postgres) | | Turso vector | Fair | Fair | Excellent | Good | Very low | | Vespa | Very good | Excellent | Very good | Moderate | High (ops overhead) | | Redis | Good | Very good | Fair | Fair | Low (if already on Redis) |

The pattern: there's no universal winner. There's a right choice for each workload.

The five patterns we now recommend

After the evaluations, here's what we actually deploy for each client shape.

Pattern 1 — Start with pgvector

For 80% of teams starting a RAG project in 2026, pgvector is the right answer. You probably already have Postgres. You already know how to back it up, migrate schemas, and secure it. pgvector piggybacks on that competence, and Postgres 18 (which we cover in a separate deep-dive) made pgvector genuinely production-grade.

You should move off pgvector when:

• Your embedding count exceeds 10-20 million and query latency becomes an issue.
• You need extremely fast hybrid search across separate keyword and vector indexes.
• You need vendor-managed operational simplicity above cost.

Until then, pgvector is not a compromise — it's the right architectural choice.

Pattern 2 — Managed Pinecone for teams that want zero ops

Pinecone remains the most polished managed offering. If your team has no infrastructure engineer and the vector store must "just work," Pinecone earns its price. The cost story is real — a mid-sized deployment can hit $2-4K/month for what a properly-sized Qdrant or Weaviate cluster would run for $400-800. If your infrastructure budget can absorb that in exchange for zero ops, Pinecone is a defensible choice.

Pattern 3 — Self-hosted Qdrant for cost-sensitive scale

Qdrant is our default for teams that outgrow pgvector but don't want to pay Pinecone premiums. Rust-based, excellent performance, generous open-source license, mature managed offering (Qdrant Cloud) if you want it. Multi-tenancy patterns are well-documented. The community is active. This is the "engineering team that knows what it's doing" choice.

Pattern 4 — Weaviate for hybrid-first workloads

If your search is heavily hybrid — vector plus keyword plus filter, with the keyword search really mattering — Weaviate is worth a hard look. BM25 is a first-class citizen, and the fusion of keyword and vector results is well-tuned. E-commerce, product catalog search, and technical documentation search often land here.

Pattern 5 — LanceDB for embedded and edge scenarios

LanceDB is the sleeper of the group. File-based, no server, queryable from Python or Rust. If your agent runs locally, or your product ships as a desktop application, or your data lives in object storage and you don't want a database at all — LanceDB is the pattern. It's also excellent for research and experimentation where you're iterating on embeddings frequently.

The specific pitfalls we've watched teams walk into

Betting on Pinecone before the workload was known. The most common mistake. A team picks Pinecone because a blog post said to, then discovers six months later that their workload doesn't justify the cost or that they need self-hosted for compliance. The migration is painful. Pick after you know your workload, not before.

Assuming "vector search" is the hard part. It rarely is. The hard parts are metadata filtering at scale, hybrid ranking, and multi-tenant isolation. Vendors that ace vector speed but stumble on filtering are the wrong choice for real production use.

Ignoring embedding model choice. The vector database matters. The embedding model matters more. A great vector store with a mediocre embedding model produces mediocre retrieval. Get the embedding model right (see: current best is text-embedding-3-large, e5-mistral-7b-instruct, or the newer Cohere embeddings depending on your task) before optimizing the store.

Under-planning for real-time updates. "How long until a new document is queryable?" is a question most teams don't ask early. Some vendors do it in seconds. Some take minutes to build indexes. If your use case requires freshness, verify the number, don't assume.

Skipping the isolation model. For multi-tenant SaaS, how you partition tenants across vector indexes affects both cost and safety. Some vendors force one index per tenant (expensive). Some fake it with metadata filtering (potentially unsafe). Some give you namespaces (usually the right answer). Pick the pattern deliberately.

Real cost numbers (illustrative, mid-2026)

Rough monthly costs for a workload of ~1M vectors, 1024-dim, 100K queries per day, hybrid search:

• Pinecone — $600-1,200 depending on tier and region.
• Weaviate Cloud — $300-600.
• Qdrant Cloud — $200-400.
• Self-hosted Qdrant on a $60/month VPS — $60-90 including backups.
• pgvector on your existing Postgres — marginal cost near zero if you have headroom, otherwise $50-200 for a bigger instance.
• LanceDB on your existing infrastructure — near zero, effectively free.

These are ballparks. Real numbers depend on your query patterns, data size growth, and operational preferences. The point: the cost gap between the cheapest and most expensive can be 10-20x for identical functionality.

For data-residency-sensitive deployments

For our clients in KSA and UAE — where data cannot legally leave the region for many use cases — the vendor choice narrows. Options that comply cleanly:

• Self-hosted pgvector on regional cloud (AWS Middle East, Azure UAE North, or private).
• Self-hosted Qdrant or Milvus on the same.
• Weaviate in a regional cluster.
• Turso with regional pinning.

Managed Pinecone can serve EU and US regions but not Middle East natively. This is a hard filter for a lot of enterprise buyers in the region.

Frequently asked questions

Do I need a vector database at all? Sometimes no. If your corpus is under 100K documents and query volume is modest, a simple in-memory FAISS index or even a naive approach is fine. Don't over-engineer.

What about embedding dimension choice? Larger embeddings (1536, 3072) give better recall but cost more to store and query. For most production RAG, 768-1024 dimensions is the sweet spot. Only go larger if you've measured a recall problem.

How often should I re-index? Depends on the vendor. Some update indexes continuously. Some batch. For most enterprise RAG, daily is fine. For e-commerce, near real-time is often required.

Are there open-source alternatives I'm missing? Chroma is still popular for prototyping but has fallen behind for production scale. Marqo is worth watching. Vespa is a serious alternative if you have Vespa expertise.

What about ScaNN / FAISS? Excellent for research and prototype. Not really "databases" — no filtering, no multi-tenancy, no operations story. Use for benchmarks; don't run production off them directly.

The strategic read

The vector database category is maturing, which means the interesting question is no longer "which one is fastest." It's "which one fits your workload and your team." The teams that spend two weeks on a real benchmark against their real data make better choices than the teams that pick based on a vendor pitch.

At Xenolve we run vector database selection as part of our AI infrastructure engagements. If you're picking a vector store for a specific workload — enterprise RAG, e-commerce search, agent memory, multi-tenant SaaS — and want an outside perspective, get in touch. We've done this evaluation on real workloads across the Middle East and India and can shortcut a lot of the exploration.

The category has grown up. Your architecture decision can grow up with it.