State of Vector Databases Q2 2026

Qdrant’s 2026 momentum shows the vector database market is fragmenting rather than disappearing.

In 2025, Elastic’s CEO Ashutosh Kulkarni declared that “Vector databases are a feature. They are never going to be a business in and of themselves.” On March 12th 2026, Qdrant raised $50M Series B, crossed 250 million downloads, and shipped version 1.17. By June 2026, the project reached 32,400 GitHub stars, up from 27,000 in December 2025. Research and Markets projects the vector database market will grow from $3.73B in 2026 to $10.6B by 2032 at a 23.5% CAGR. A dying category does not produce those numbers.

Qdrant growth snapshot

Ashutosh described real commodity pressure, but only for a part of the market. PostgreSQL with pgvector now absorbs workloads under 50M vectors and reduces total cost of ownership (TCO) by 40–60%. Hierarchical Navigable Small World (HNSW) and Inverted File Flat (IVFFlat) indexes enable Approximate Nearest Neighbor (ANN) search, while PostgreSQL maintains ACID compliance that native vector databases do not offer. Combining keyword search and in-database vector similarity within a single system eliminates the need for a separate vector store. That is the market segment Ashutosh’s argument accurately captures.

Above 50M vectors, the performance gaps become visible. pgvector stores embeddings directly inside PostgreSQL tables. A dataset with 1M (1,536-dim) vectors consumes roughly 6 GB for the vectors alone, with HNSW indexing adding another 3–4 GB at default settings. Index build time increases with each new workload, and latency climbs from 50ms to 800ms past the 10M-embeddings mark on a 1TB RAM instance.

Billion-scale workloads expose what relational databases cannot sustain without continuous reconfiguration, quantization, and on-disk indexing. TripAdvisor indexes 1B+ multimodal user reviews on Qdrant. HubSpot runs Qdrant for its Breeze AI assistant. A general-purpose database with a vector data type struggles at that scale.

The death narrative and the vector database category growth are valid in Q2 2026, but they define different parts of the same market. Where you sit on the scale, workload, and deployment spectrum determines which argument applies to your infrastructure decisions this quarter.

The vector DB market is growing. The question is which segment each vendor can serve.

The Trifurcation Thesis: One Market Splitting into Three

The vector database market is not collapsing to a single winner. There are three simultaneous splits across scale, workload type, and deployment environment. Most architectural decisions in 2026 are getting the wrong answer because teams are only evaluating vector count.

Vector database market trifurcation across scale, workload, and deployment

Scale: Where Postgres wins and where it stops

Every major cloud hyperscaler and traditional relational database now ships pure vector search. PostgreSQL has pgvector and pgvectorscale, Oracle has Database 26ai, Microsoft SQL Server added a vector data type, Amazon RDS uses pgvector, and Google’s Cloud SQL for MySQL has similarity search. Stack Overflow’s annual Developer Surveys show PostgreSQL held the top database position from 2023 to 2025.

Below 50M vectors, Postgres with pgvector and pgvectorscale supports production workloads without requiring a separate vector engine. For teams already on Postgres, adding vector search with pgvector is one CREATE EXTENSION vector; command. TigerData benchmarked pgvectorscale against Qdrant on the Cohere Wikipedia 50M (768-dim) dataset, targeting 99% recall on AWS r6id.4xlarge instance. pgvectorscale returned 471.57 queries per second (QPS) against Qdrant’s 41.47 QPS, an 11x throughput difference on a single-node configuration.

Postgres won on throughput, but Qdrant won on p95 latency at 36.73ms against pgvectorscale’s 60.42ms, and index build time at 3.3 hours against 11.1 hours. As Desmond Tan, our vice president of engineering, puts it,

At a billion-vector scale and under strict latency budgets, a general-purpose database bolting on a vector type does not hold up. The hard part was never nearest-neighbor search. It is the operational envelope, like recall stability under continuous updates.

Purpose-built engines increase index build speed, handle sharding across nodes, manage disk offloading, and maintain predictable p95 latency under concurrent writes that 100M+ vector workloads demand. NVIDIA built a multimodal data mining system on Milvus, indexing 10B+ sensor data points from test fleets, and achieved a 30x cost reduction without architectural redesign. When you are tuning autovacuum and maintenance_work_mem to hold recall steady, your workload has moved past Postgres with pgvector.

Workload: AI agents broke the read-optimized assumption

Dedicated vector databases were built for read-heavy Retrieval-Augmented Generation (RAG) pipelines. In 2026, AI agents issue 10x more queries than humans. They write frequently and create index bloat, traffic spikes, and multi-tenancy pressure that read-optimized indexes do not handle well.

As one eToro backend engineer posted on X,

The 2026 question is no longer which vector database to pick. It is which retrieval strategy the workload actually needs. Most production failures come from forcing every problem into the same simple retrieve-then-generate pipeline.

Cloud-first vector databases are responding to write-heavy workloads with auto-scaling, native row-level isolation, and real-time streaming. But the market is also rethinking whether the database should live in the cloud at all.

Deployment: The axis cloud-native vendors cannot address

For industries handling sensitive data, vector embeddings must meet stringent compliance standards under laws like the EU AI Act, US CLOUD Act, General Data Protection Regulation (GDPR), and Health Insurance Portability and Accountability Act (HIPAA). Gartner predicts that by 2030, more than 75% of European and Middle Eastern enterprises will repatriate their virtual workloads due to geopolitical risk, up from less than 5% in 2025. Cloud vendors provide compliance certificates, but keeping the database on-premises gives teams direct control over data governance and reduces the single points of failure that cloud infrastructure introduces.

The right infrastructure in Q2 2026 depends on your vector count, operational fit, and deployment constraints. This table shows you how to decide.

Pinecone: The Paradox of the Quarter

Pinecone is positioning Nexus as the agentic architecture that replaces RAG, backed by a single internal benchmark no one has reproduced. That unverified test, not the launch itself, is what determines whether Nexus belongs in your agent infrastructure this quarter.

Pinecone’s revenue dropped from $27M in 2024 to $14M in 2025, Notion churned, and The Information reported the company was exploring a sale in August 2025. Nine months later, on May 4th, 2026, they shipped Nexus, their most ambitious product launch yet. If you’re running vector workloads on Pinecone, that sequence is the context you evaluate Nexus against.

Nexus is Pinecone’s attempt to move up the agentic AI stack. It combines a context compiler that produces task-specific vector artifacts from raw vector database information, and a composable retriever that serves those artifacts with per-field citations and deterministic conflict resolution. Pinecone CEO Ash Ashutosh called the launch an architectural shift:

RAG was built for human users. Nexus was built for agentic users because their language is very different.

KnowQL, a declarative query language, followed the Nexus release. It enables AI agents to specify intent, provenance, output shape, latency budgets, and confidence requirements without interpreting raw vectors directly. Pinecone’s Nexus internal benchmark on SEC 10-K filings reported completion rates rising from 50–60% to above 90%, a 95% reduction in Large Language Model (LLM) token usage, and a 30x increase in task execution speed. None of these results have been validated in production deployments.

Nexus’s mechanism of compiling reasoning once before any query runs and storing the results as reusable artifacts is directionally sound. Gartner’s VP Analyst Arun Chandrasekaran described it as a meaningful step beyond simple retrieval: “Unlike traditional RAG, which relies on pure semantic search at runtime, architectural compilation embeds structural logic into the metadata layer, which can boost time to response and provide better reasoning.” Janakiram MSV pushes back on KnowQL specifically, arguing that “KnowQL has to clear the standardization bar SQL cleared, and standards do not get declared into existence by a single vendor.” 

Desmond agrees the Nexus principle is sound but not new, calling it “caching applied to retrieval.” On the single-test-case benchmark, he’s direct: “Before recommending Nexus, I would need independent reproduction on a non-cherry-picked suite, a clear account of the stale-artifact failure mode, and an honest reckoning of lock-in.” He would not commit agent infrastructure to it this quarter because “KnowQL is a single-vendor query language and SQL became a standard by committee, not by declaration.”

Pinecone claims its vector engine serves 9,000 customers and 800,000 developers. The company pioneered the managed vector database category in 2023 and reached $750M in valuation after a $100M Series B. They built their founding message on RAG, then launched Nexus as the product that moves beyond it. But Nexus still depends on Pinecone’s vector database for retrieval speed, storage, and scale. Ash confirmed that “the vectors are still stored and managed by the Pinecone vector database.” The market claim that RAG-era infrastructure is obsolete does not hold when agentic systems still live on it.

The sale report remains unconfirmed, and the benchmark gains are unvalidated. But your embedding pipeline is what you control, regardless of what happens next. Document the model, version, dimensions, and chunking strategy today. Keep your retrieval substrate portable so a compilation layer remains an optional optimization you can replace.

Are Vector Databases the Right Substrate for Agent Memory?

Vector databases handle one category of agent memory well, and degrade on the other. Forcing one index type to serve different retrieval needs is how most production AI architectures fail.

Agent memory runs two distinct workloads. One-shot semantic retrieval over a stable document library is read-heavy and batch-indexed. That is RAG, and HNSW and IVF indexes handle it well. The second part is the working agent memory. It involves frequent writes, iterative retrieval, fact extraction, and entity resolution. A read-optimized index degrades under this workload.

Hindsight’s Ben Bartholomew was partially right when he said, “‘Agent memory means vector database’ has become a kind of folk wisdom… Agent memory is something else, and treating the two as the same problem is what produced the bad default in the first place.” The table below maps how RAG and agent query patterns differ across five retrieval dimensions.

Anthropic removed vector search from Claude Code in May 2025 and replaced it with grep. Cursor, Windsurf, Cline, Devin, and Sourcegraph Amp followed this pattern, dropping vector similarity for tool-driven search.

Weaviate’s product team spent two weeks integrating Engram, their vector-backed memory product, with Claude Code via Model Context Protocol (MCP). Claude ignored it entirely, explaining, “I default to MEMORY.md because it’s always loaded: zero latency, zero tool calls, guaranteed in context. There’s no reason to reach for an external tool when the primary memory store is already present.” A coding agent traverses a graph of dependencies, imports, function calls, and type definitions. That workload demands determinism and exact matches, rather than semantic similarity.

The Hindsight team uses a multi-strategy approach that merges and ranks four parallel retrievers on PostgreSQL: semantic search, entity-based retrieval, temporal filtering, and graph traversal. On the LongMemEval benchmark, this hybrid approach achieved 94.6% accuracy against Mem0’s vector-primary system’s 49%. grep and hybrid retrieval deliver better results than pure vector search for coding agents and frequently updated document collections under 10M. Keeping a vector index synchronized with an active codebase requires frequent re-embedding, which is costly at scale and delays retrieval freshness.

Hindsight argues that a vector database lacks the temporal awareness, separation of concerns, and conflict-resolution capabilities that working agent memory demands. The problem is applying vector search to the wrong agent constraint.

&AI CTO Herbie Turner confirmed that Qdrant is “the ground truth” for their patent agent handling over one billion vectors. Reddit still runs billion-scale vector data on Milvus. AI memory frameworks like Mem0 use vector databases as the underlying retrieval infrastructure, paired with a knowledge graph for entity relationships. Vector databases hold long-term domain facts across sessions. For large, heterogeneous knowledge bases where retrieval accuracy drives business outcomes and missed results are expensive, vector search remains the right approach. It is also the practical retrieval strategy for natural-language queries in unstructured document search systems. 

Qdrant CEO Andre Zayarni explained the query volume gap that makes vector databases relevant: “Humans make a few queries every few minutes. Agents make hundreds or even thousands of queries per second, just gathering information to be able to make decisions.” Agents waste up to 85% of compute on context recovery. Vector databases make that recall fast and accurate at scale.

About Author

Acerca de Tahiya Chowdhury

Tahiya Chowdhury es directora de producto de Actian Zen, donde dirige la estrategia de la plataforma de datos periféricos más sólida del sector. Gracias a su experiencia en MongoDB y Goldman Sachs, Tahiya se especializa en crear productos que se sitúan en la intersección entre las necesidades de las grandes empresas y la velocidad de los desarrolladores modernos. Le apasiona eliminar la complejidad de la infraestructura de datos, lo que permite a los equipos de ingeniería pasar más rápidamente del prototipo a la producción.