Pinecone: HNSW Search, Metadata Filtering, Namespaces, and RAG Scaling

Pinecone is routinely described in tutorials and comparison posts as "an HNSW-based vector database," and the assumption carries real weight when a team is choosing infrastructure for a production retrieval-augmented generation pipeline: HNSW's behavior under heavy write churn, its memory footprint, and its need for rebuilds after large deletions are well documented, and buyers reasonably expect to inherit those trade-offs when they pick a vector store built on it. Pinecone's own architecture documentation disputes the premise directly, stating that the company has never run HNSW in any of its offerings, past or present. Since March 2024, every new Pinecone project has run exclusively on the serverless architecture, and since August 18, 2025 the older pod-based product has been closed to new sign-ups entirely, with existing pod-based indexes being migrated toward serverless. Understanding what actually executes a query, how metadata filtering interacts with billing, and how namespaces map to multi-tenant design is what determines whether a Pinecone-backed RAG system behaves predictably once it leaves the prototype stage.

THE INDEXING LAYER PINECONE ACTUALLY RUNS, NOT THE ONE MOST COMPARISONS ASSUME.

How automatic, size-based algorithm selection replaced the HNSW graph that most competing engines still expose directly.

According to Pinecone's own engineering material, the legacy pod-based product ran the Pinecone Graph Algorithm (PGA), a proprietary design derived from Microsoft's Vamana and FreshDiskANN line of graph indexes rather than HNSW itself. The current serverless engine replaced that graph approach entirely with a different model: incoming vectors are written into immutable "slabs" stored in object storage and organized in an LSM-tree-style hierarchy, and the indexing method applied to each slab is chosen automatically by size rather than configured by the user. Slabs holding up to roughly 10,000 records use Ananas, a proprietary method built on the Fast Johnson-Lindenstrauss Transform; slabs up to roughly 100,000 records use PQFS, Pinecone's fast-scan product quantization; larger slabs, from roughly 100,000 up past a million records, use IVF clustering layered with PQFS, scanning only the clusters relevant to a given query instead of the full slab.

The logic behind this tiering is a trade-off between freshness and cost. Newly written vectors land in small, cheap-to-search slabs so they are queryable immediately without waiting for an index rebuild, and get folded into larger, more heavily compressed slabs as data ages and volume grows, which keeps memory and compute costs bounded at scale. For workloads with sustained, high query rates or record counts in the billions, Pinecone offers Dedicated Read Nodes (DRN), which entered public preview in December 2025: DRN provisions reserved memory and local SSD capacity per shard (roughly 250 GB each) so that queries are served from warm storage instead of fetched on demand from object storage, and additional replicas scale query throughput close to linearly. Pinecone has published a customer benchmark of 1.4 billion vectors served at approximately 5,700 queries per second with 26 ms p50 and 60 ms p99 latency on DRN; this is a vendor-reported figure rather than an independently verified one, and should be treated as directional rather than a guarantee for a different dataset or query pattern.

........

Mode	Availability	Indexing approach	What it is for
Pod-based (legacy)	Closed to new sign-ups since August 18, 2025; existing indexes being migrated	PGA, a proprietary graph algorithm derived from Vamana / FreshDiskANN	Being phased out; Pinecone states migration to serverless typically completes in under 30 minutes at no cost
Serverless On-Demand	Default for all new projects	Automatic per-slab selection: Ananas (≤10K records), PQFS (≤100K), IVF + PQFS (100K–1M and above)	Variable, bursty RAG workloads billed per request
Dedicated Read Nodes	Public preview since December 2025	Same slab engine, served from reserved warm memory and local SSD instead of on-demand object-storage fetches	Sustained high-QPS, latency-sensitive production traffic

........

··········

METADATA FILTERING AND NAMESPACES: TWO WAYS TO NARROW A QUERY, WITH DIFFERENT COST PROFILES.

Why the isolation strategy chosen for multi-tenant RAG changes the bill, not just the schema.

Pinecone integrates metadata filtering into the retrieval path itself rather than applying it purely before or after the vector search runs. The company's ICML 2025 research paper on serverless metadata filtering frames the underlying design choice as a spectrum between ad-hoc filter application and pre-computed filter representations, and the production engine leans on structures built over the LSM slab layout so that a selective filter narrows the candidate set a query actually has to score, instead of requiring a full pass over an unfiltered result set afterward. In practice this means a highly selective filter, such as a tenant identifier matching a small fraction of an index, tends to make a query faster rather than slower — a property that naive post-filtering implementations elsewhere in the vector database space do not share. Two hard limits apply regardless of how the filter is structured: filterable metadata is capped at 40 KB per record, and the $in / $nin operators each accept at most 10,000 values, which becomes a real constraint when a filter is built from a large per-user allow-list rather than a small set of categorical tags.

Namespaces work differently: every read or write operation targets exactly one namespace, and a single query cannot span multiple namespaces. Pinecone documents namespace ceilings ranging from 100,000 up into the millions depending on plan tier, and recommends namespaces as the default multi-tenant isolation strategy over metadata filtering for three concrete reasons stated in its own documentation. First, physical separation: each namespace's data is stored separately rather than commingled behind a filter. Second, cost: a query against a single tenant's namespace is billed only for scanning that namespace, while a metadata-filtered query against a shared namespace is billed for scanning the entire namespace regardless of how selective the filter turns out to be — Pinecone's own cost model bills roughly one read unit per gigabyte of namespace data scanned, so filtering after the scan rather than isolating before it directly inflates the bill as a shared namespace grows. Third, offboarding: deleting an entire namespace when a tenant leaves is close to instantaneous, compared with issuing a filtered delete across matching records. Metadata filtering remains the right tool when strict isolation is not a requirement, or when a query legitimately needs to read across multiple tenants at once — a shape namespace-scoped queries cannot express by design.

··········

SCALING RETRIEVAL QUALITY AND COST TOGETHER FOR RAG PIPELINES.

Hybrid search, integrated inference, and the pricing mechanics that decide what a production index actually costs.

Pinecone supports two distinct patterns for combining dense and sparse retrieval. The first stores dense and sparse vectors in the same record within a single index using the dot-product metric, blending scores at query time as alpha times the dense score plus (1 − alpha) times the sparse score; because BM25-style sparse scores are unbounded positive values while dense cosine-style scores sit roughly in [-1, 1], both are normalized before blending so the sparse component does not dominate by scale alone. The second pattern, cascading retrieval, queries separate dense and sparse indexes independently, merges the two result sets — typically with reciprocal rank fusion — and passes the merged candidates through a reranking model. Pinecone reports, on BEIR benchmark data, an average 12% improvement from combining dense and sparse retrieval over either alone, and on TREC datasets an average 24% improvement (up to 48% in the best case) when cascading through a reranker versus dense-only search; these are vendor-published benchmark figures rather than independently reproduced results, and actual gains vary by corpus and query distribution.

Integrated inference lets embedding and reranking happen inside the same API call instead of requiring a separate service: Pinecone's own llama-text-embed-v2 (dense) and pinecone-sparse-english-v0 (sparse) models handle embedding, while pinecone-rerank-v0, Cohere's cohere-rerank-3.5, and bge-reranker-v2-m3 are available for reranking. Several operational ceilings are worth designing around before they surface in production rather than after: query top_k is capped at 10,000, query response size at 4 MB, upsert batches at 2 MB or 1,000 vector records (96 records when text needs to be embedded on the way in), and bulk import jobs at up to 1 TB per on-demand job (unlimited on Dedicated Read Nodes) across as many as 100,000 files.

........

Plan	Price	Billing model	Notes
Starter	Free	Hard caps; usage above the cap is blocked, not billed	2 GB storage, 2M write units/month, 1M read units/month, 5M embedding tokens per model/month, 500 rerank requests/month, 1 GB egress/month
Builder	$20/month flat	Higher fixed caps than Starter; usage above the cap is blocked, not billed	Exact quotas are not published by Pinecone; positioned for solo developers and small teams wanting a predictable flat cost
Standard	$50/month minimum	Pay-as-you-go beyond the minimum	Storage, read/write units, embedding tokens, reranking, and egress billed individually past the minimum spend
Enterprise	$500/month minimum	Pay-as-you-go beyond the minimum	Same billing model as Standard, with higher default object limits (indexes, namespaces, backups) per project

........

··········

WHEN PINECONE'S ARCHITECTURE FITS A RAG WORKLOAD — AND WHEN IT DOES NOT.

Matching the engine's actual design, not its reputation, to the shape of the retrieval workload.

What a team adopts when it picks Pinecone is a proprietary, automatically managed slab engine tuned for elastic scaling and immediate write freshness, not a hosted HNSW index with familiar tuning knobs. That distinction has practical consequences. For bursty or early-stage RAG workloads where traffic is unpredictable and the priority is not operating vector infrastructure, the serverless On-Demand default is the appropriate starting point, and namespaces should be the multi-tenant boundary chosen from day one — retrofitting namespace-based isolation onto an index originally built around a shared namespace and metadata filters means re-ingesting the data under a new structure, not flipping a configuration flag. For workloads with sustained, predictable query volume and strict latency requirements, Dedicated Read Nodes are worth pricing against on-demand read-unit costs once monthly query volume reaches the point where per-request billing would exceed a reserved node's flat hourly rate, which is precisely the trade-off Pinecone designed DRN to address. For teams that specifically need transparent control over the nearest-neighbor algorithm itself — tunable graph parameters, self-hosting, or the ability to audit exactly what structure is searched — Pinecone's non-configurable, proprietary engine is a mismatch at any tier, and that requirement points toward an engine that exposes HNSW directly rather than toward Pinecone under the assumption that it is one.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org