Pinecone Vector Database: Indexing, Metadata Filtering, Namespaces, and RAG Scaling

Pinecone has never run HNSW, in either its current serverless architecture or the pod-based system it replaced in 2024. The confusion is understandable — HNSW is the default choice for most vector databases, and Pinecone's own marketing rarely leads with the correction. What Pinecone actually runs is a set of proprietary algorithms selected automatically per data partition: Ananas for small partitions, PQFS for medium ones, and IVF with PQFS for large ones. The reason is structural rather than a matter of preference. HNSW builds a graph that has to stay resident in memory to be fast, and Pinecone's serverless index lives in distributed object storage — the S3-class layer that makes the storage effectively unlimited also makes a memory-resident graph the wrong tool for the job. Namespaces and metadata filters are the two mechanisms Pinecone gives a developer to narrow a search before it runs, and getting the choice between them right is what separates a namespace strategy that scales cleanly from one that quietly inflates a bill.

··········

THE INDEXING ENGINE: ADAPTIVE ALGORITHMS SELECTED PER SLAB.

How Pinecone decides which algorithm handles a given partition of data, and why no single algorithm covers the full range.

Pinecone stores vector data in immutable units called slabs, and it dynamically selects an indexing algorithm based on how large a given slab is. Small slabs, up to roughly 10,000 records, use Ananas, a proprietary algorithm built on the Fast Johnson-Lindenstrauss Transform. Medium slabs, up to roughly 100,000 records, use Product Quantization Fast Scan, based on asymmetric distance computation. Large slabs, above roughly 1 million records, use Inverted File indexing, where vectors are clustered and only the relevant clusters get scanned per query, with each cluster itself built as a small PQFS index.

The selection is automatic and invisible to the developer — there's no algorithm to choose, no parameter to tune, and no re-ingestion required when Pinecone updates the underlying implementation. That trades control for operational simplicity: Milvus, by comparison, exposes eleven-plus index types including HNSW, IVF_FLAT, IVF_PQ, and DiskANN, and expects the operator to pick the one that fits a given workload's recall and memory trade-off.

........

Indexing algorithm by slab size

Slab size	Algorithm	Basis
Up to ~10K records	Ananas	Fast Johnson-Lindenstrauss Transform
Up to ~100K records	PQFS	Product quantization, asymmetric distance computation
Above ~1M records	IVF + PQFS	Clustering, with each cluster indexed as PQFS

........

The consequence of this design shows up directly in latency. Pod-based indexes, the older pre-2024 architecture, publish roughly 30ms at the 99th percentile under typical load on p2 pods. Serverless indexes run a baseline 20-80ms depending on index size, higher than pod-based but without any capacity planning on the operator's side. Self-hosted Milvus with hand-tuned HNSW can push under 10ms — a real gap for applications where sub-10ms latency is a hard requirement, and a gap Pinecone's own architecture doesn't try to close, since the serverless design optimizes for elastic scale and freshness over raw single-query speed.

··········

NAMESPACES AND METADATA FILTERING: TWO DIFFERENT WAYS TO NARROW A SEARCH.

When to isolate data structurally versus when to filter it at query time, and what each choice costs.

A Pinecone index is the top-level container that defines vector dimension and similarity metric; within it, records live in namespaces, and every query, upsert, delete, and update targets exactly one namespace. Metadata filtering works differently — it attaches key-value pairs to individual vectors and narrows a search within whichever namespace the query already targets, based on those attached values.

The two mechanisms aren't interchangeable, and Pinecone's own documentation recommends namespace-based isolation over metadata filtering specifically for multi-tenant applications: assign each tenant a dedicated namespace rather than filtering a shared namespace by tenant ID. The cost difference is direct and quantified — a query against a 1GB namespace costs 1 read unit, while the same query against a 100GB namespace using a metadata filter to reach the same subset of data costs 100 read units, because the filter still has to be evaluated across the full unfiltered namespace before narrowing down.

Namespace limits set the ceiling on this strategy: Standard and Enterprise plans support up to 100,000 namespaces per index, with million-scale namespace counts available for specific use cases on request to Pinecone support. Metadata filters carry their own separate limit, enforced since a 2026 update — a maximum of 10,000 values per $in or $nin operator in a single filter expression, which caps how many discrete IDs a single filtered query can target directly.

Pinecone also enforces request-per-second limits at the namespace level: 100 requests per second per namespace, on every plan, on top of the existing read-unit and write-unit billing. That limit exists specifically to contain noisy-neighbor effects in multi-tenant deployments, where one tenant's traffic spike could otherwise degrade query latency for every other tenant sharing the same index.

··········

PRICING: WHERE THE SERVERLESS MODEL REWARDS SOME WORKLOADS AND PUNISHES OTHERS.

The published unit rates, and why the same rate card produces wildly different bills depending on write pattern.

Pinecone serverless bills three things separately: storage at $0.33 per GB per month, read operations at $8.25 per million read units, and write operations at $2.00 per million write units. There's no capacity to provision and no minimum commitment — the free tier covers one index and 2GB of storage, the Starter tier runs $70 a month, and Standard starts at $231 a month, with Enterprise custom-priced for multi-region replication and higher namespace ceilings.

........

Serverless unit pricing

Component	Rate	Notes
Storage	$0.33/GB/month	Charged regardless of query volume
Reads	$8.25/1M read units	Metadata filters increase RU cost per query
Writes	$2.00/1M write units	Scales directly with write frequency
Free tier	1 index, 2GB storage	No card required
Starter	$70/month	Higher storage and namespace limits
Standard	From $231/month	Production-scale limits

........

The published rate card is accurate, but the pricing calculator built around it assumes a read-heavy RAG profile: infrequent writes, moderate and predictable query volume, stable storage growth. That assumption breaks cleanly for AI agent memory workloads, which write on every reasoning loop, query multiple namespaces per step, and grow storage continuously as episodic history accumulates rather than staying flat. Independent cost analysis of production agent deployments has found the resulting bill running 3 to 5 times higher than the calculator's estimate, because the write-frequency field — the single input most teams underestimate — drives both write-unit charges and storage growth simultaneously in a workload the calculator wasn't modeled around.

A concrete reference point: an enterprise index holding 10 million vectors at 1,536 dimensions with 50GB of metadata, under a standard RAG access pattern, runs to roughly $64 a month in direct Pinecone costs — storage, one-time write load, and five million monthly reads combined. That figure holds for the read-heavy case the calculator assumes; it does not hold once the workload shifts to continuous agent writes across many namespaces, which is precisely the case the 3-5x gap applies to.

··········

Pinecone's actual advantage over a self-hosted vector store isn't raw query speed — Milvus with tuned HNSW beats it on that axis, and reviewers say so directly. The advantage is that nobody on the team ever touches a shard, tunes an index parameter, or gets paged for a compaction job, and for datasets under roughly 50 million vectors, that operational absence is worth more in engineering time saved than the per-query premium costs in cloud spend. The decision that actually matters before signing a Pinecone contract is not storage or read-unit pricing — it's whether the workload is read-heavy and RAG-shaped, where the published calculator is trustworthy, or write-heavy and agent-shaped, where it should be treated as a floor rather than an estimate, and the write-frequency input modeled against real agent-loop rates before committing to a plan.

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org