Pinecone Release Notes

Delivering scoped, accurate context, without pre-labeling entire datasets

Semantic search returns results that are close in meaning, not necessarily results that answer what someone meant to ask. A person scanning through can tell the difference and skip past the ones that miss the mark. An agent can't: it takes whatever comes back as ground truth and starts acting on it, with nobody checking the work first.

The sharpest version of that gap is unstated context: a query can be perfectly clear to the person asking it and still leave out information a system needs to answer it correctly. This post walks through that failure mode using a public dataset of 10,000 CNN news articles from Hugging Face, spanning 2022 to 2024, with each article's text and topic label stored as metadata, and shows how Pinecone's new text match filters fix it without requiring the dataset to be pre-labeled for every case in advance.

Follow along with the queries and results below in this notebook.

The ambiguity problem

Take the query "Who are the top presidential candidates?". A user in the United States asking this almost certainly means the U.S. presidential election. Nothing in the query says so.

Dense vector search alone returns this:

Rank Article ID Score Excerpt 1 3433 0.8168 First round of voting, featuring 11 presidential candidates, takes place on April 23. Le Pen and Macron are tipped to... 2 8054 0.8138 Presidential candidates for France's mainstream parties failed to make the second round. Poll favorite Emmanuel Macron... 3 3421 0.8130 France holds its first round of the presidential election on Sunday. Candidates react quickly to the death of a pol...

Every one of these is about the French election, and every one is a legitimate semantic match, yet none of them answer the question the user actually meant to ask.

The obvious fix is to have the user rewrite the query as "top US presidential candidates," but that comes with two costs. First, it pushes the burden of writing a precise query back onto the user, who came in with what felt like a simple question. Second, in an agentic pipeline, a bad first retrieval costs more than a re-query: ask an agent to chart polling trends and analyze who's rising and falling, and if it builds that analysis on French election data, the tokens spent generating the wrong answer are wasted, so are the follow-on tool calls, and the error compounds at every step downstream. Multiply that across a few thousand queries and the cost stops looking incidental.

Restricting results by country with metadata filtering is possible, but it means labeling every record for every dimension that might matter, in advance: country, election year, local versus national race. Any filter dimension discovered after the fact requires reprocessing the entire dataset, which for production systems can mean billions of records, before it can be applied.

The solution: text match filtering

Full Text Search from Pinecone, now in public preview, supports text match filters: a lexical query that restricts the candidate pool for a semantic search to records matching specific text, without pre-labeling metadata for every case an application might need to handle.

Applying a text match filter for "United States" to the same query changes the candidate pool before the semantic search runs:

Rank Article ID Score Excerpt 1 5326 0.8012 (CNN) Former Vice President Joe Biden swept to victories across southern states on Super Tuesday, but Vermont Sen. Bernie Sanders... 2 7641 0.7992 (CNN) The Human Rights Campaign Foundation announced Thursday it will host a CNN Democratic presidential town hall in California... 3 9859 0.7987 (CNN) President Donald Trump and Democratic presidential nominee Joe Biden have taken very different positions on a range of polic...

The query, model, and index are identical to the search above. The only difference is that the candidate pool was scoped to records containing "United States" in the article body before the vector search ran, and all three results now land on the actual U.S. race.

Where this generalizes

News search makes the ambiguity easy to see, but the same pattern shows up anywhere a query assumes context it doesn't state: industrial manuals scoped to a machine number or error code, insurance claims scoped to a policy number or type, legal search scoped to a case or jurisdiction. Most semantic search applications run into some version of this, since most queries leave something unstated.

These filters chain: combine them with boolean operators, stack them with metadata filters, or layer on more text match filters against other fields, and the candidate pool narrows along several dimensions in a single query.

What changes for agentic applications

An agent has no step where it double-checks that a semantically close result is actually the right one for the task. Whatever filtering needs to happen has to happen before the results reach the agent, not after. Text match filtering moves that correction into the query itself, without requiring the dataset to be pre-labeled for every filter an application might eventually need. For pipelines where a bad retrieval turns into a chain of wasted tool calls, narrowing the candidate pool at query time is cheaper than catching the error after the fact.

Original source

TLDR

Pinecone's V2 sparse index organized posting data in document-major blocks, which forced every query to load the entire index regardless of which terms it contained. V3 reorganizes the index around terms: each term owns its own sequence of posting blocks, and a query only loads the blocks for terms it actually references. From disk, this reduces I/O by 151× for SPLADE queries and 1,428× for BM25 queries, with no loss in recall, and measurably better recall for BM25.

Sparse indexes at Pinecone

In March 2025, Pinecone launched sparse-only indexes, bringing keyword and lexical search into the same serverless platform as dense vector retrieval, supporting both BM25 and learned sparse models including SPLADE and Pinecone's own pinecone-sparse-english-v0.

Sparse retrieval is built on inverted indexes, a data structure at the heart of search engines for decades. Each term gets mapped to a posting list: a record of every document containing it and a relevance score for that document. Traditional scoring functions like BM25 weight terms by frequency within a document and rarity across the corpus. Learned sparse models like SPLADE go further, using a transformer to assign context-aware weights and expand a document's representation to include related terms. A document about machine learning might score non-zero on "training" and "inference" even without those words appearing verbatim. Pinecone's implementation runs this on the MaxScore algorithm, which makes retrieval fast at scale by skipping documents that can't beat the current top-k threshold rather than scoring every candidate.

Supporting sparse vectors alongside dense, operating a separate Elasticsearch or Solr cluster is no longer needed, and the search pipeline gets further consolidated..Sparse and dense indexes are queryable together in a single index (sparse for keyword matching, dense for semantic breadth) with Pinecone managing both.

The scale problem

The architecture that powered V1 and V2 organized posting data in what's called a document-major layout. Documents are divided into groups by ordinal position (1–1000, 1001–2000, and so on). Each group gets a block on disk containing the interleaved posting data of all terms in any of the group’s documents.

At query time, the search algorithm has to read each of these blocks, because any block might contain postings for any of the query's terms. A query for "apple" and "orange" reads the block covering documents 1–1000, then 1001–2000, then every other block through the entire index. There's no way to skip ahead without reading.

When an index fits in memory, this is survivable. SIMD scoring is fast, and scanning several gigabytes at memory bandwidth completes in hundreds of milliseconds. But as sparse indexes gained adoption, larger workloads appeared. A billion-vector SPLADE index can run to hundreds of gigabytes. At that size, keeping the full index in memory is expensive. And in a serverless environment where many users share the same underlying hardware, it often isn't feasible: memory is allocated dynamically across workloads, so one large index needing most of the available memory delays other active indexes.

When an index can't stay in memory, every query becomes a series of disk reads—nd reads from disk are orders of magnitude slower than memory. The V2 disk benchmarks make this concrete: every SPLADE query took 3,407 milliseconds regardless of what it was searching for, at p50, p90, and p99. The completely flat distribution exposed disk throughput as the limiting factor.

For billion-scale indexes, the only path to sub-second latency used to be dedicated hardware sized to keep the full index in memory.

What V3 changes

We needed a way to reduce disk reads. Specifically, instead of loading the whole index into memory, we needed to devise a method to identify and load only the relevant postings. That way, a query touching 2 terms out of a 50,000-term vocabulary still had to read all 50,000 terms' worth of posting data (because they were packed together indistinguishably).

V3 overhauls the layout so queries can skip directly to what they need.

• Term-major layout: Each term gets its own blocks on disk; a query only loads data for the terms it contains.
• In-memory term directory: A compact map keeps every term's disk location in memory, so finding a term costs no I/O.
• Metadata-first block skipping: A small summary block per term lets the algorithm decide what to skip before loading any posting data.
• Compressed posting blocks: Doc IDs and scores are compressed per-term, reducing block sizes up to x2.5.

Organizing by term instead of by document range

V3 flips the grouping strategy: it groups posting data by term instead of document range. All of "apple"'s postings live in their own contiguous sequence of blocks on disk; all of "orange"'s postings live in another sequence elsewhere. A query then reads only the blocks for the terms it actually contains. A SPLADE query typically includes dozens of non-zero terms; a BM25 query, just a few. Against a vocabulary of tens of thousands, both are a small fraction of the index to load.

A compact directory that lives in memory

Reorganizing around terms creates a new problem: with posting data scattered across potentially tens of thousands of separate locations on disk, how does the search algorithm find a given term's blocks without scanning the index?

V3 solves this with a term directory, a compact map stored in the index metadata that records, for each term, where its posting data begins on disk. The metadata loads into memory when the index is opened and stays there. Every term lookup is an in-memory operation; finding a term's disk location costs no I/O.

The directory uses Elias-Fano encoding, which compresses sorted integer sequences while preserving O(1) lookup. For 100,000 terms, the result fits in about 300 KB (small enough to stay in the CPU’s L2 cache).

Structure Size (100K Terms) Lookup Sorted array of pairs ~800 KB O(log n) Hash map ~2.4 MB O(1) Elias-Fano ~300 KB O(1)¹

¹ O(1) positional access by term ID; the term dictionary resolves strings to dense integer IDs upstream.

Deciding whether to load a block before loading it

Even after locating a term's posting data, not every block for that term may be worth loading. A term that appears in many documents will have many posting blocks. MaxScore pruning can skip the weaker ones, but applying that logic requires knowing each block's maximum possible score before deciding to load it.

V3 stores this information in a metadata block at the start of each term's data. Before any posting blocks are read, the search algorithm loads this metadata block (a small, fast I/O) and gets back a summary for every posting block the term contains: the range of document IDs in the block, the highest score any posting in the block achieves, and the number of postings. With that summary in hand, three classes of skip decisions happen without reading any posting data: metadata filtering, MaxScore pruning, and position skipping.

Compressing what's left

The blocks that aren't skipped need to be as small as possible to reduce I/O and better fit in the memory cache during scoring. V3 applies two compression techniques that only work best with its term-major layout.

Document ID compression.

Rather than storing each document ID as a full 32-bit integer, V3 stores only the offset from the block's minimum document ID. The minimum ID is already recorded in the metadata block, so the decoder knows the reference point before reading any posting data. The maximum offset within a block determines how many bits each offset needs. For example, a block spanning documents 50,000 to 50,128 only needs 7 bits per offset rather than 32. SIMD operations pack and unpack each posting block’s values in a single pass with no branching. The result is 2–2.5× compression for tightly clustered blocks, and meaningful compression even for spread-out ones.

Block Spread Bits per ID Total Tight (range < 256) 8 256 B Medium (range < 64K) 16 384 B Wide(range < 1M) 20 448 B

A full posting block fits in a handful of L1 CPU cache lines.

Per-term score quantization.

Scores are stored as single bytes mapped to a score range. Whereas V2 used one range across all terms in a document block to represent score, V3 uses each term's own range. This finer mapping explains V3’s increased recall, especially for BM25 models.

Finding the right heuristics

The performance-critical decisions—window sizing, merge strategy, and scoring granularity—depend on hardware cache geometry and posting list density in ways that resist analytical derivation.How these parameters got tuned turned out to be the most unconventional part of the build, and in some ways more interesting than the structural changes it was optimizing.

The approach: property-based tests and recall benchmarks as the fitness function, with Claude driving hundreds of iterations testing algorithmic combinations, and a human reviewing direction and killing runs that were clearly going wrong. When a property test failed or recall dropped, the loop backtracked. When throughput improved with recall holding, the change was retained. The heuristics that shipped (window sizes tuned to L1 cache, adaptive behavior across posting densities) came from this iterative, empirical process. It worked because the test harness was rigorous enough to trust, as a false pass would have been worse than a slow run.

Results

Benchmarks run on MS MARCO, a standard retrieval corpus of 8.8 million documents using SPLADE embeddings (averaging ~45 non-zero query terms) and BM25 (averaging ~3 query terms). BM25 gains are larger because sparse query vectors reference fewer terms, leaving more of the index for V3 to skip.

Scanning under I/O pressure (from disk)

This is the case V3 was built for: an index too large to keep resident, where every query pays in disk reads. Under V2, that meant reading the whole index on every query, no matter how few terms it touched.

Metric V2 V3 Change Recall@100 1.0000 1.0000 -- Bytes loaded / query (p50) 3,396 MB 22.5 MB 151x less Latency p50 3,407 ms 128 ms 27x faster Latency p90 3,407 ms 252 ms 14x faster

V2's latency is flat across percentiles. Every query did the same work, so every query took the same time— a little over three seconds regardless of what was asked. V3 executes those same queries in a couple hundred milliseconds, scaling by the number of terms involved rather than the flat size of the index.

Metric V2 V3 Change Recall@100 0.9840 0.9840 -- Bytes loaded / query (p50) 714 MB 0.5 MB 1,428× less Latency p50 715 ms 6 ms 119× faster Latency p90 719 ms 13 ms 55× faster

For a typical short query, V3 reads 1,428× less data and returns in milliseconds, because it pays only for the terms it contains. The recall a user gets back is identical.

The payoff shows up directly in production. One customer running billion-scale sparse queries migrated to V3 and went from multiple seconds per query to 40 milliseconds on the same hardware. For their users, that’s the difference between a search that stalls and one that feels instant. It’s also what makes billion-scale sparse retrieval affordable on shared serverless infrastructure, rather than something that demands dedicated hardware sized to the worst case.

Conclusion

The document-major layout had one flaw that scale exposed: queries couldn't skip all irrelevant data. Every query read the entire index, so a two-term lookup costed as much as scanning everything. This worked well when indices could fit in memory.. Once they didn't, every query fell back to disk and the design didn't hold.

V3 reorganizes posting data around terms rather than document ranges:

• each term owns its blocks
• in-memory directory finds them with no I/O
• per-block metadata lets the algorithm skip what it doesn't need before reading it from disk
• per-term compression shrinks what remains

A full-index scan becomes a read that touches only the terms a query contains.

This algorithm runs in all of Pinecone's sparse indexes today (thanks to the compaction process, changing algorithms was a completely online procedure, without disrupting any ongoing operations). Queries pay for what they use, recall holds, and billion-scale sparse retrieval runs on shared serverless infrastructure alongside dense retrieval in a single pipeline.

Original source

Seven weeks ago, we announced early access to Pinecone Nexus, to deliver knowledge to AI agents.

We’ve since partnered with a broad cohort of users spanning massive data, high complexity, and stringent accuracy, latency and cost requirements. Today, we are opening up public preview.

Distributed enterprise knowledge, compiled into something agents can rely on.

Agents built around frontier models are great at world knowledge, complex reasoning, and synthesizing information across disciplines. Finding specific information buried across files is a search problem, one vector databases have been chipping away at for years.

There's a third kind of knowledge that neither of those touches: business context. It's what a three-year employee knows without searching; which internal process doc reflects how things actually work today, what the quarterly goals mean in practice, how a policy in one department connects to a decision in another. It lives distributed across your enterprise in contracts, wikis, HR docs, meeting notes, support tickets, and financial records. Most of it has been written down somewhere, often many times over, but written down isn't the same as compiled, and an agent walking into a task needs the latter.

Every time an agent starts a task, it starts from zero on all of this. It can piece things together on the fly, but the cost shows up in tokens, in time, and in answers that are half right.

Pinecone Nexus is a knowledge engine that closes that gap. It compiles an enterprise's distributed knowledge into a structured layer agents can query directly, shifting token spend out of the per-query retrieval loop and into a one-time curation step.

Today, we're opening it up to anyone with a business use case. Pinecone Nexus is now in Public Preview.

What's Ready

Starting today, request access to Pinecone Nexus and see what curated knowledge does for agentic workloads on the dimensions that matter: cost, speed, and accuracy.

Nexus is built for bounded corpora where agents need to reason across documents. It's at its best on the kind of corpus where a single question touches dozens of files and standard retrieval starts falling apart.

There are two ways in:

Preview Playground

request access today and get a live environment to connect your data, design a Context, and run real queries. It's enough to validate the approach on something real before committing to a deployment.

BYOC Deployment

for production workloads, request a dedicated deployment. The cluster runs in your VPC with no shared infrastructure. Pinecone never has access to your data, your documents don't leave your infrastructure, and there's no shared compute with other tenants. Our deliberate focus on this deployment model is to align with the needs of enterprises where data residency, security, and compliance are non-negotiable.

See Nexus in Action

The demo above uses a synthetic financial services corpus of a household's complete set of financial records including their goals, plans, meeting notes, and portfolio documents. It’s the kind of corpus where a question like, "How are the Chens tracking against their retirement goals?" touches dozens of documents across multiple years, and unlike Nexus, a standard retrieval system would return chunks instead of fully-formed answers.

The Knowledge Engine, Explained

The results enterprises in Early Access are seeing aren’t a product of better prompting or a smarter model. They come from a different approach to how knowledge is organized before any query arrives. (See our previous blog, Nexus in the Wild: Real Results from Our Early Access Customers)

Connectors handle ingestion: Local file upload, Box, and Microsoft OneLake are live today, with Google Drive, Slack, GitHub, Notion, Confluence, and S3 close behind.

A Workspace is the top-level container: the boundary around a team or business unit. Connectors and other shared resources live at the Workspace level, so the natural mental model is one Workspace per team that owns its own data sources and access controls: a support org, a legal team, a data science group.

Inside a Workspace, your data is organized into Contexts: one per dataset or knowledge domain. Sources flow through Nexus's curation layer, guided by a Manifest that turns raw documents into structured knowledge artifacts tuned to the domain. The Manifest is the blueprint for how the corpus should be understood.

Tasks run the actual work inside isolated Sandboxes: import to ingest and clean sources, curate to build artifacts per the Manifest, and search to query via KnowQL. Each workflow can employ an ensemble of models, with the right model picked for each step. Everything surfaces through a single interface: KnowQL, the Query Interface into Nexus. Agents, chatbots, AI search applications, recommendation systems all tap into the same knowledge layer through one consistent surface.

SMEs in the loop

The people who know what questions matter, and what knowledge structure would answer them, usually aren't the engineers building the pipeline.They're the patent attorney who knows how patent standards are organized. The M&A analyst who knows which document categories need to be cross-referenced for a clean diligence answer. The revenue leader who knows which signals in a Gong transcript actually predict churn.

The Manifest is how we bring that person into the loop. A subject matter expert can design a blueprint defining the artifact types and relationships that encode their domain knowledge into the curation layer before any query runs. The agent isn't left to figure out the structure of the corpus at query time. It inherits the SME's understanding of it.

This is a different model than prompt engineering. The model isn't being coached at query time, it's being handed a knowledge layer that was designed by someone who actually knows the domain. The difference is between an agent that retrieves the most relevant chunk and one that reasons over a corpus already structured by someone who understood it. The answer comes out precise and fast, with the reasoning pointed in the right direction from the start.

Knowledge doesn't stay static. Regulations change, products evolve, and a corpus that was accurate six months ago develops what we call knowledge drift. Nexus lets SMEs re-curate: update the Manifest to reflect new requirements, rebuild the knowledge layer, ship. The agent stays current because the person who understands the domain stays in control of the knowledge layer.

More Benchmarks

Since opening Early Access, we've kept benchmarking. Different industries, different corpus shapes, same question: does the Manifest-driven curation model hold up when the knowledge problem gets harder or stranger? Three of those benchmarks are below.

Q2: Support Knowledge Base for Financial Services

Domain: Digital Banking / Financial Technology

Q2 builds digital infrastructure for financial institutions. Their support team works through thousands of technical knowledge base articles as part of standard triage, searching them every time a client calls in with an issue.

The articles themselves are easy to find. Most real support questions, though, have answers that live across several of them, and a wrong answer to a financial institution carries real downside, so accuracy ends up being the deciding criterion.

Q2 ran this benchmark themselves. They got early access to the preview environment, ingested their sources, designed a Manifest from a pre-built template, curated the artifacts, and ran the evaluation without Pinecone team in the loop.

Corpus: A sample of Q2's internal technical support knowledge base, covering the breadth of questions their support team handles daily.

Eval set: 20 questions across 6 categories: single-article lookups, two-article reasoning, multi-article synthesis, persona-based support scenarios, and customer cases. Designed to mirror the real question types Q2's support teams face daily.

Results:

F1 Score: 95%
Avg Recall (1–5): 4.70
Avg Precision (1–5): 4.70

For Q2, accuracy was everything, and 95% on their hardest questions was the number that made the case. Jesse Barbour, Chief Data Scientist at Q2, put it best:

"We can easily stand up a vector database and run RAG (and agentic search) over our documentation corpus. The hard part is getting an agent to reliably and efficiently assemble the right knowledge for genuinely difficult questions. In our own evaluations, Pinecone Nexus answered a set of complex support and compliance questions with 95% accuracy. And the fact that it has the ability to do it while keeping token costs down, not driving them up, makes it even more compelling." — Jesse Barbour, Chief Data Scientist, Q2

A Legal Research AI Company: Coverage and Reliability Over EU Case Law

Domain: Legal Research / LegalTech

This benchmark, run with a company building AI tools for legal research, tested Nexus on the task at the center of their product: answering substantive legal questions over EU case law and legislation. Nexus ran against an agentic-RAG baseline and a coding agent, with the same model composing every answer. Only the retrieval architecture changed, so any difference in the results is attributable to it.

The questions span the shapes a real legal researcher asks: looking up what a specific provision requires, tracing how a doctrine has been applied across cases, assembling every relevant precedent on a topic, and reasoning across multiple regimes at once. These are hard for standard retrieval for the same reason municipal records and support tickets are: the answer is rarely sitting in one document.

Corpus: 30,000 documents (~1.1 GB) of CJEU and General Court case law plus EU legislation, spanning 2021–2026.

Eval set: 35 legal research questions across 8 categories, including provision lookups, doctrine synthesis, cross-case and cross-regime reasoning, coverage and enumeration questions, precedent chains, and out-of-corpus negative controls.

Results:

Metric | Nexus | Agentic RAG | Coding Agent
Completion rate | 100% | 66% | 6%
Accuracy | 87% | 45% | 4%
Avg Tokens per query | 9k | 80k (9x) | 135k (15x)

The completion gap tells most of the story. The coding agent completed just 2 of 35 questions, browsing 30,000 documents by listing and reading files doesn't scale to a corpus this size. The RAG baseline did better but fell apart on doctrine synthesis, cross-case reasoning, and coverage questions, the shapes that require many sources assembled into one answer. On 12 of those, it never made it to composing a response at all. Nexus completed every question in the set, and even on the ones both systems answered, it was more accurate.

On a control question about U.S. securities law, asked of a corpus that contains only EU law, Nexus recognized the question was out of scope and said so. The other two systems fabricated answers.

A Leading Data Protection and Security Vendor: Cross-Document Reasoning Over Municipal Records

Domain: Enterprise Data Management

This benchmark, run with a data protection and security vendor, tested Nexus on a corpus where the documents themselves aren't technically complex, but they're structured so that almost no question can be answered from a single one of them.The corpus is 598 documents of municipal meeting minutes from a major city, spanning 2022–2025 across 13 governing bodies. Almost no question in the eval set can be answered from a single document. Counting a council member's attendance requires reasoning across roughly 40 documents. Resolving a project location requires joining an agenda item to its parcel number, applicant, and owner. Reading a motion's full vote requires extracting a structured roster from a narrative paragraph.

These are exactly the queries that expose the problem with standard retrieval. Chunk the corpus, embed it, and there's no way to answer "How many times did Mayor Smith preside over a city council meeting between 2022 and 2025?" without the agent looping back dozens of times to reassemble partial answers.

Corpus: 598 documents, one per meeting. 13 governing bodies. 4 years of data. Multi-session meetings with repeated structures.

Eval set: 100 questions across 13 categories including attendance counts, motion votes, officer history, project locations, deadlines. All cross-document by design.

The Manifest: 12 artifact types, including dedicated SQLite-backed tables for Meeting Attendance, Motion Log, Deadline Log, and Project Location.

Results:

Accuracy: 90% vs (RAG Baseline: 65%)
Curation cost (one-time, 598 documents): $0.0038 per doc
Query cost: $0.0069 per question

Curating 598 documents into 12 structured artifact types cost $2.31 and took 34 minutes. Every subsequent query runs against that curated index at a low average cost, with no per-query retrieval loop accumulating tokens. The knowledge gets compiled once.

A leading data protection and security vendor, a digital banking infrastructure provider, and a legal research AI company don't have much in common. One use case is reasoning across years of government meeting minutes, another is answering technical support questions for banks, and the third is legal research across tens of thousands of case law documents. But all three hit the same wall with standard retrieval, and all three saw the same thing when they switched to a knowledge layer built for their corpus: accuracy went up, costs came down, completion rates climbed, and questions that used to require multiple retrieval loops just got answered.

The shift is to compile knowledge upfront instead of reassembling it on the fly. When the knowledge layer is structured before a query arrives, the agent reads from a layer that already knows the shape of the corpus, rather than rebuilding that understanding from raw retrieval every time it gets asked something.

Start Building

If your agent setup has hit its ceiling on your corpus, has accuracy that won't improve, token costs that won't close a business case, latency that doesn't fit a live workflow… the issue is almost always in the knowledge layer, not the model.

Pinecone Nexus solves those problems. And when you're ready to go to production, BYOC deployment means your data never leaves your infrastructure. No shared environment, no data residency concerns, no compromises on security. Your cluster, your VPC, is fully isolated.

Get started with the Nexus Public Preview
Make your agents more accurate, faster, and cheaper
Request Access
Talk to Sales

Original source

(Cohere Rerank 4.0 Fast)

(Cohere Rerank 4.0 Fast) is now generally available as a reranking model on Pinecone. It succeeds cohere-rerank-3.5, improves relevance quality, and supports multiple rerank fields. Cohere Rerank 4.0 is hosted on Azure AI under the Global Standard deployment type, and requests may be processed in regions outside the United States. With this release, cohere-rerank-3.5 is deprecated:

• Through July 31, 2026: cohere-rerank-3.5 continues to serve requests as before.
• August 1, 2026: requests to cohere-rerank-3.5 are automatically served by cohere-rerank-4-fast.

No code change is required for the transition, but note two differences before you migrate:

• Relevance scores differ. cohere-rerank-4-fast returns different scores than cohere-rerank-3.5. If your application relies on hard-coded score thresholds, re-tune them against cohere-rerank-4-fast before August 1.
• Billing counts units differently. The per-unit rate is unchanged at $2.00 per 1,000 rerank units. One rerank unit covers a query plus up to 100 documents, with documents longer than ~500 tokens auto-chunked into ~500-token chunks that each count toward that 100. As a result, cohere-rerank-4-fast can bill multiple units for a large request, whereas cohere-rerank-3.5 billed one unit per request.

To control the transition yourself, migrate your rerank requests to cohere-rerank-4-fast before August 1. For model details and parameters, see Reranking models.

Original source

After working with enough production deployments, a pattern becomes clear: a stale, undersized, or under-resourced index doesn't go down. It returns the wrong results. The problem is that without continuous visibility into index health — record counts, upsert rates, storage utilization, latency trends — there's no signal that anything is wrong until the AI application has already been serving degraded results.

This post introduces pinecone-field/pinecone-monitoring: an open-source stack with pre-built Grafana dashboards, Prometheus metric collection, and support for both Pinecone SaaS (Serverless) and Bring Your Own Cloud (BYOC) deployments.

What's in the Stack

The monitoring solution is built on two industry-standard open-source tools:

Prometheus handles metric collection and time-series storage. It scrapes the Pinecone Metrics API at regular intervals, capturing operational data across all your indexes. For BYOC deployments, it also collects Kubernetes infrastructure metrics via Node Exporter.

Grafana provides the visualization layer — pre-configured dashboards that surface the right data, with built-in alerting capabilities so your team can respond to signals before they become incidents.

The repo supports three deployment configurations:

• SaaS Only: Docker Compose-based setup for teams using Pinecone Serverless. Operational in minutes.
• BYOC Only: Kubernetes-native deployment using Helm charts, with pod-level and node-level infrastructure visibility.
• BYOC + SaaS: A unified monitoring instance that covers both index types simultaneously, ideal for teams running mixed environments.

Why Monitoring a Vector Database Is Different

Monitoring a vector database isn't the same as monitoring a relational database or a REST API. Availability and latency are table stakes; what matters here is the health of high-dimensional index structures, the performance of approximate nearest-neighbor operations, and in BYOC deployments, the Kubernetes layer underneath.

Record counts, upsert rates, and storage utilization tell a different story than uptime alone. A gradual p99 increase over several days might indicate an index approaching a resource ceiling, a shift in query patterns, or a regression from a recent deploy. That signal doesn't exist without time-series data. And unlike databases where a DBA team controls load, Pinecone workloads are shaped by application code, users, and ML pipelines — which makes unexpected changes in operation rates often the first sign something has gone wrong.

What it enables

Proactive operations. Continuous metric collection with Grafana alerting lets teams set thresholds on latency baselines, pod CPU and memory utilization, operation rate deviations, and index storage growth. Issues caught at the signal stage get resolved in minutes; issues caught after users notice get resolved in hours, if not longer.

Root cause analysis. When incidents happen, the dashboards provide a complete operational timeline across every Pinecone operation type — queries, upserts, fetches, updates, deletes — with latency at p50 and p99. BYOC deployments add per-pod CPU, memory, and storage alongside Kubernetes node health. Post-incident reviews have data; recurring issues get traced rather than treated.

Workload change detection. AI applications change fast. New model versions, feature launches, and pipeline modifications all shift how Pinecone gets used — sometimes intentionally, sometimes not. A 5x query spike after a feature launch is expected but worth confirming. A background process looping through redundant upserts is invisible without operation rate tracking. A drop in query traffic signaling a broken integration gets caught before users do.

Cost visibility. Pinecone costs are tied to usage. Without visibility into operation rates and storage growth, cost surprises are common. With it, teams can correlate application behavior with usage spikes, identify inefficient patterns, validate that optimizations are actually reducing load, and set alerts before usage hits unexpected thresholds.

Capacity planning. The stack supports infrastructure decisions grounded in trend data rather than incident response. Months of index growth, query volume, and utilization history make it possible to project when a BYOC cluster needs additional nodes, how latency has responded to index growth, and what headroom looks like across pod memory.

Multi-project visibility. The stack supports multiple Pinecone projects in a single deployment. For platform teams managing staging, production, and customer-specific environments, unified visibility makes it straightforward to validate that a deployment change didn't introduce a regression, or that a new environment is performing consistently with an established one.

BYOC infrastructure health. For organizations running BYOC for data residency, compliance, or performance reasons, the stack brings Kubernetes-level observability to Pinecone infrastructure that previously required custom solutions. Pod CPU and memory, node health, filesystem utilization, and storage metrics are all captured and visualized — consistent with the tooling, alerting, and runbooks applied to the rest of the Kubernetes estate.

SLA documentation. Uptime and latency data matter beyond operations. Ninety days of Grafana data supports reliability conversations with business stakeholders, informs SLA commitments, and provides documentation for compliance or audit purposes.

Getting started

For SaaS monitoring, Docker Compose brings up Prometheus and Grafana with pre-configured dashboards in a few minutes. The only prerequisites are a Pinecone API key and project details.

For BYOC, Helm charts deploy the stack into the cluster. Node Exporter is included for infrastructure-level metrics, with deploy and uninstall scripts for lifecycle management.

All dashboards are pre-built and provisioned automatically.

View the repository on GitHub

Original source

We gave three enterprises a knowledge engine. Here's what happened to accuracy, latency, and costs.

For the past year, most enterprise AI discussions were about capability. The question that replaced it is about cost and reliability. AI is expensive to run at scale, and accuracy and latency still break down on the hardest corpora. When teams look at where their inference spend is actually going, most of it isn't on reasoning. It's on retrieval loops that run before the model can say anything.

Pinecone Nexus addresses this at the infrastructure layer. Rather than assembling knowledge at query time, it compiles structured artifacts from a corpus before any query arrives, tuning the retrieval pipeline to the specific shape of the data. We launched four weeks ago and have been engaged with early access users with real enterprise datasets. Our early enterprise partners are seeing real results. Here's what happened to their accuracy, latency, and costs after Nexus.

The Benchmark

For each customer, we ran Nexus against the most common pattern in enterprise agent deployments today: chunk the corpus, embed the chunks, use hybrid retrieval. The agent loops (run the query, rerank, read the top chunks, retrieve again) until it has enough context to answer.

That approach can produce correct answers. The question is at what cost in tokens, time, and consistency, and whether that cost holds at enterprise scale.

Three KPIs:

• Token cost. How many tokens does a single query consume? At enterprise volume, this determines whether the economics of an agentic deployment hold.
• Accuracy. Does the agent return the correct answer, repeatable across runs? Each eval set in our benchmark was built from human-labeled questions with expected answers drawn from the actual corpus. Answers were graded by an LLM judge (claude-sonnet-4-6) on a 0–1 scale against the expected output.
• Latency. How long does a query take, end to end? For agents embedded in live workflows, user-facing products, automated pipelines, or deal support, time to answer matters.

All three trace back to the same dynamic. Agentic RAG assembles knowledge at query time: retrieve chunks, rerank, read, decide what's missing, loop again. The loop runs on a generic index built once from the raw source, with no knowledge of the domain, the query types, or the reasoning the task requires. Each iteration is the agent compensating for what the index doesn't know and working around an absence, not a foundation.

Nexus works differently. Before any query arrives, it derives structured artifacts from the corpus shaped to the subject matter, the query types, and the reasoning the agent will need to do. The agent retrieves precisely and reasons immediately.

Melange: Standard Essential Patent Search

Domain: Intellectual Property / Patent Litigation

Melange Technologies runs an autonomous, large-scale prior art search engine used by law firms in patent invalidation and litigation. Their core product is an agentic search system which filters the total corpus of around 140 million patent documents down to the most relevant dozen and provides litigators with a first draft of the legal analysis necessary to prosecute their case. The work is nearly fully autonomous with human verification only at the final stage before delivery.

Melange’s next plan of expansion involves Standard Essential Patents, or SEPs. An SEP is a patent that claims technology required to comply with an industry standard. For example, any company building a phone with 5G capability must implement portions of the 5G technical standard. If a patent covers one of those mandatory portions, then practicing the standard may necessarily practice the patent. Patent licensing has become a multi-billion dollar industry, with SEPs at the center of the most valuable and contested disputes.

This has two important implications for the industry. First, it is critical to determine whether a patent is actually essential to the standard. That analysis can be expensive and time-consuming, often requiring human domain experts to compare patent claims against long, technical standards documents line by line. Second, standards documents themselves can serve as prior art, potentially invalidating patents that claim technology already disclosed during the standards-development process.

In just release 1 of the 3GPP technical standard, there are roughly 1,800 documents including 2.3 GB of relevant documents. The pilot evaluated a focused 29-spec slice of the 5G NR standards (~31 MB, converted to markdown). These specifications originate as .docx/.doc files dense with embedded tables and normative requirement language.

Corpus: 3GPP Release 18, 1,800 .docx/.doc files, ~2.3 GB, covering 5G NR specifications, protocol standards, interface definitions, and normative requirements. Pilot evaluated on a 29-spec NR slice (31 MB, converted to markdown).

Eval set: 30 SEP-candidacy questions, each a patent-style claim evaluated against the standards corpus for whether a finalized, mandatory 3GPP requirement necessarily practices it. Every answer is one of five verdicts (mandatory, conditionally mandatory, optional, forbidden, or absent) with the exact spec, clause, and information element cited.

Agentic RAG averaged ~20 retrieval steps per question on this corpus. The loop does not converge on dense, clause-referenced technical standards because the index carries no knowledge of how the standards are structured or what the query requires. Nexus organized the standards into addressable requirement artifacts before any query ran. The correct clause was retrieved directly, at 5.9K tokens versus 201K tokens.

Business impact: At 97% lower token cost, a previously cost-prohibitive autonomous patent search product becomes economically viable at scale. Latency under one minute per query means the workflow fits live litigation timelines. The accuracy improvement directly reduces attorney review time.

"These early results are genuinely exciting: a 34x reduction in token cost and queries resolving in under a minute on one of the hardest problems in our space tells us we're pointing in the right direction. Adding a purpose-built knowledge engine to Pinecone’s AI infrastructure is already showing signs of real business impact, and we're looking forward to evolving this together as Nexus matures to fully fit the demands of patent search at scale." — Joshua Beck, CEO, Melange

M&A Due Diligence

Domain: Financial Technology / Investment Management

The customer is a large financial technology company serving asset managers, hedge funds, and private equity firms. Their clients operate in document-heavy environments where extracting precise answers from large document sets directly affects deal outcomes and regulatory risk.

The use case evaluated here is M&A due diligence, which is a representative scenario for this customer's client base, where a deal dataroom for even a mid-market acquisition spans hundreds of documents across 10+ categories: audited financials, capitalization tables, customer contracts, IP filings, HR records, real estate leases, tax schedules, legal governance docs. Questions aren't contained within a single document. They require reasoning across all of it simultaneously.

The dataset is a full synthetic M&A dataroom for a $42M ARR enterprise SaaS company, structured across 10 category folders with files spanning PDFs, Excel workbooks, and markdown, covering the full complexity of a live deal room in a controlled, evaluable form.

The questions that matter here are inherently multi-hop. "What capital-structure feature in Vantage's preferred stock affects the equity-value waterfall to common shareholders?" requires reasoning across the cap table, preferred stock terms, and liquidation preference documents simultaneously. "What contingent legal liability could impair Vantage's projected cash flows or warrant a DCF risk discount?" requires connecting IP filings, litigation records, and financial projections across three separate folder categories. No single document holds the answer. The question only resolves when the full dataroom is treated as a unified knowledge surface.

Corpus: 90 documents across 10 category folders (PDFs, XLSX, and markdown) covering company overview, audited financials, ARR schedules, cap tables, customer contracts, IP filings, HR records, tax documents, real estate leases, and process documents.

Eval set: 30 multi-hop M&A diligence queries requiring cross-document reasoning.

Nexus resolved each question in a single retrieval step against RAG's approximately 10 iterative steps. The accuracy improvement holds on the hardest multi-hop queries, where agentic RAG's loop repeatedly retrieves incomplete context across documents and cannot close the reasoning gap without re-querying. Nexus derived artifacts from the dataroom that mapped the cross-document relationships before any query arrived.

Business impact: Due diligence workflows that required analyst hours to synthesize across folders now complete in seconds. At 92% lower token cost and 48% lower latency, the economics of deploying AI across deal pipelines are fundamentally different. Higher accuracy on multi-hop questions reduces the risk of missed liabilities or misread financial structures.

Revenue Intelligence from Gong Transcripts

Domain: SMS Marketing / E-commerce SaaS

The sales and CS teams for a leading SMS marketing and sales platform for e-commerce brands run a high volume of customer-facing calls every week, pricing conversations, onboarding calls, renewal discussions, competitive deal cycles, all captured in Gong.

The challenge is that insights locked in those transcripts are largely inaccessible at scale. Questions like "Which competitor is mentioned far more than any other across these calls?" or "Name several accounts where RCS is a major topic of discussion" require synthesizing patterns across dozens of calls simultaneously. Searching one transcript at a time, which is what an agentic loop does, is too slow and too expensive for a live revenue workflow. The signal is in the aggregate.

The dataset is one week of real Gong call exports: structured JSON transcripts covering sales, CS, and pricing conversations, with company-specific tracker data (message rate, list growth, churn indicators, competitor mentions, expansion signals) embedded throughout.

Corpus: 217 Gong call transcripts, ~45 MB of structured JSON call data spanning sales, pricing, and customer success conversations with full tracker and topic metadata.

Eval set: 40 revenue intelligence queries requiring cross-call synthesis, trend identification, and pattern recognition.

The accuracy improvement here is the largest of the three cases and reflects the fundamental mismatch between agentic RAG and aggregate synthesis workloads. An agentic loop over 217 transcripts is iterating through documents one at a time, searching for partial answers, and reassembling them into a response. It cannot see across the full corpus simultaneously. Nexus derived structured representations of the call data that made cross-call patterns directly addressable. The nearly 2x accuracy gain is what corpus-level compilation looks like in practice.

Business impact: Revenue intelligence queries that required manual analyst review become automatable. Competitive signals, churn indicators, expansion patterns, and pricing sensitivities become queryable in real time across the full call corpus. At 85% lower token cost, running these queries continuously as new calls come in becomes economically viable.

Results Across Three Customers

Three customers, three industries (financial services, intellectual property, revenue operations), three knowledge problems. Nexus outperformed agentic RAG on accuracy, latency, and token cost across all three.

The pattern held regardless of corpus shape, query type, or domain. In every deployment, agentic RAG started from the same place: a generic vector index built from the raw source, with no knowledge of the domain, the query types, or the reasoning the task requires. The retrieval loop that follows isn't incidental to that design. It's what happens when the index carries no knowledge of the domain, query types, or task structure.

Nexus gets to the root cause. The artifacts it derives from an M&A dataroom are structurally different from the ones it derives from a patent standards corpus or a Gong transcript database, because the subject matter, query types, and reasoning requirements are different. By the time a query arrives, the knowledge layer has already been shaped to the problem. The agent retrieves precisely and reasons immediately rather than sifting through generic chunks hoping to assemble enough context to answer.

The practical consequence is direct: projects that couldn't clear the business case now can. At 92–97% fewer tokens, inference costs that were prohibitive at enterprise volume become manageable. At 48–77% lower latency, agents that couldn't fit live workflows now do. At accuracy rates that hold on hard corpora, deployments that required constant human review become autonomous.

Apply for Early Access

Nexus is built for teams building agents over enterprise knowledge: documents, contracts, filings, call transcripts, technical specifications. If agentic RAG has hit its ceiling on a corpus, the issue is almost always in the retrieval loop, not the model.

Enterprises with a hard knowledge problem can apply for Early Access and run a benchmark on their own data before public preview. We'll work with you.

Original source

Pinecone Nexus integration with Microsoft OneLake moves reasoning upstream and delivers trusted knowledge to AI agents querying enterprise data, at a fraction of the cost of traditional approaches.

SAN FRANCISCO, June 3, 2026 / PRNewswire / — Pinecone, trusted knowledge infrastructure for AI, today at Microsoft Build announced a new integration connecting Pinecone Nexus and Microsoft OneLake. This integration changes how enterprise AI agents get the information they need. It shifts the process from slow, expensive retrieval to fast, structured, cited responses built directly from data organizations already have in the Microsoft ecosystem.

Common AI agents spend the majority of their time and tokens trying to find relevant information in the data they have access to. They retrieve raw data, stitch it together, and send it to a frontier LLM to make sense of it. In production, at scale, this breaks down: task completion rates drop 60%, and token consumption and related costs become unpredictable.

Pinecone Nexus is a knowledge engine purpose-built for AI agents. Instead of making agents assemble raw data at runtime, Nexus does that work in advance, dynamically building structured, task-optimized contexts called artifacts. Each artifact is scoped to a specific task; it pulls the right data, applies the right permissions, and formats the result so the agent can use it directly.

Agents query artifacts through KnowQL, a query language purpose-built for knowledge retrieval. A KnowQL query specifies what the agent needs to know, the required output format, citation requirements, and latency budget. Nexus handles the rest. Early results show a 95%+ reduction in frontier LLM token usage, 30x faster task execution, and completion rates above 90%.

Organizations using Microsoft Fabric have already unified their data, including documents, tables, and Power BI semantic models, in OneLake. The Nexus integration connects directly to OneLake with no manual imports or upload steps. When an agent needs to complete a task, Nexus queries OneLake, builds an artifact scoped to that task and the user's access permissions, and returns a structured, cited response through KnowQL. Every answer traces back to its source. No data is exposed beyond what RBAC permissions allow. PII is tagged at ingest and governed centrally.

For technical teams managing AI in production in Microsoft Fabric, the new integration enables a direct path from operating on raw data to building on knowledgeable artifacts that deliver accurate results at scale, without rebuilding data pipelines or managing separate retrieval infrastructure.

"The data enterprises need to power their AI agents already live in Microsoft OneLake,” said Ash Ashutosh, CEO, Pinecone. “Nexus builds task-specific artifacts from this data, and gives AI agents a clean, structured, cited interface through KnowQL, 30x+ faster and at a fraction of what traditional retrieval approaches cost."

Today, every team building AI agents invents its own retrieval interface. The result is fragmentation, where agents retrieve information differently across platforms, governance is applied inconsistently, and cost controls break down at system boundaries. KnowQL defines a common language. An agent specifies the question, the required output structure, the citation standard, and the latency budget. A KnowQL-compliant knowledge engine handles the rest.

“Microsoft OneLake offers a unified data foundation for AI applications and Agents,” said Dipti Borkar, VP and GM, Microsoft OneLake and Fabric Ecosystem. “Pinecone Nexus does the hard work of fetching, assembling, and reasoning over OneLake data up front, so our customers' agents spend less time making tool calls, burn fewer tokens, and get accurate answers faster."

Nexus is built for enterprises with compliance requirements. Artifacts are assembled per task, scoped to RBAC and ABAC permissions, and versioned. Every answer cites its source. PII tagging and LLM processing rules are configured once and applied consistently. Token consumption is tracked across users and workloads through a unified dashboard.

Early access to Pinecone Nexus with OneLake integration is available now. Learn more and apply here.

About Pinecone

Pinecone is the trusted knowledge infrastructure for AI at scale. Its vector database and knowledge engine, Pinecone Nexus, power accurate, performant AI applications for more than 9,000 customers and 800,000 developers worldwide. Pinecone's mission is to make AI knowledgeable. For more information, visit pinecone.io.

Media Contact:

Mike Sefanov

[email protected]

Sr. Director, Communications

Original source

Getting a large dataset into Pinecone

Getting a large dataset into Pinecone has always been the first step before anything useful can happen — search, evaluation, production traffic. Bulk import is the fastest path to that point, and the cost to do it just dropped significantly.

Starting June 1, bulk import is free up to 1 TB. Standard and Enterprise plans get a $250 credit applied automatically. After 1 TB, import runs at $0.25/GB – down 75% from $1/GB.

How bulk import works

Bulk import is already the fastest way to get a large dataset into Pinecone because it skips the standard write path entirely. Upsert acknowledges every request, sequences it, holds it in the memtable, and flushes before the index builder picks it up -- guarantees that matter for continuous writes, but overhead for a large one-time load. Bulk import reads directly from object storage into the index builder. The result is the same populated index through a more efficient path.

Semantic search over 200 bird species in a few lines

A terabyte of bulk import covers roughly 130 million records at 1024 dimensions with typical metadata. That's enough to load a substantial evaluation corpus, stand up a semantic search prototype against real data instead of a toy slice, or seed a production index before incremental writes take over.

The workflow has three steps regardless of scale: turn raw data into embeddings, write those embeddings as Parquet files in object storage, then call start_import. The example below uses the bird search corpus -- ~200 North American bird Wikipedia articles -- because it runs end-to-end in a few minutes. The same code handles a 1 TB load with a larger input dataset.

Index configuration for this example

The bird search index uses dedicated read nodes (t1, 1 shard). See Create a dedicated read nodes index for the full setup.

Generate the embeddings

(Note: If you already have Parquet files with vectors you can skip this step.)

Bulk import expects vectors, not raw text, so the first step is converting each bird article into a 1024-dimensional embedding. The loop below batches articles into groups of 96 and sends each batch to Pinecone's hosted inference API using the multilingual-e5-large model. input_type="passage" tells the model these are documents being indexed (as opposed to queries), and input_type="passage" handles articles that exceed the model's context window.

[Code snippet for embedding generation]

Write Parquet files to S3, partitioned by namespace:

[Code snippet for upload_to_s3 function]

Each Parquet file contains three columns: id, values (the embedding), and metadata (a JSON object). The S3 folder structure maps directly to namespaces -- files under s3://bucket/folder/namespace1/ load into namespace1.

Start the import:

[Code snippet for start_import call]

The job runs asynchronously. Check status in the console or via describe_import:

[Code snippet for describe_import call]

Once complete, query as normal:

[Code snippet for querying the index]

What this scales to

The bird corpus is small by design -- it's a runnable example. The same pattern handles datasets that are orders of magnitude larger. A single import operation supports up to 1 TB of data or 100 million records across up to 100 namespaces. The setup is identical regardless of scale: configure a storage integration for S3, GCS, or Azure Blob Storage, format data as Parquet files organized by namespace, and call start_import.

One constraint: bulk import doesn't work on indexes with a schema definition, including full-text search and integrated embedding indexes. Use the documents upsert API for those.

Get started

Full pricing, limits, and storage integration setup are in the docs.

Original source

The Builder plan now supports serverless indexes in every generally available cloud region, the same regions available on the Standard and Enterprise plans. Previously, Builder indexes were limited to the us-east-1 region of AWS.

Highlights

• All supported regions — Create Builder serverless indexes across AWS, GCP, and Azure, including us-west-2 (Oregon), eu-west-1 (Ireland), eu-central-1 (Frankfurt), ap-southeast-1 (Singapore), us-central1 (Iowa), europe-west4 (Netherlands), and eastus2 (Virginia).
• Lower latency and data residency — Deploy indexes closer to your application or in a region that meets your data residency requirements, without upgrading to Standard or Enterprise.
• No pricing change — Builder remains a flat $20/month plan with no usage overages.

The Starter plan continues to support the us-east-1 region of AWS only. For the full list of supported regions, see Cloud regions. For plan quotas, see Database limits.

Original source

For the technical deep dive into how FTS is built, see Full Text Search: Architecture and Design

One index, text and vectors together

When semantic search hit production scale, the default move for retrieval was to embed text and search by meaning. As such, the surface area of what a query could match expanded: the same corpus, searched semantically, contained more retrievable signal than it had before.

But expanded coverage cuts both ways. The same property that lets a vague query find a relevant document also makes it harder to pin down an exact one. Precision for searching on specifics (i.e. a product SKU, a legal citation, a person's name, an error code) doesn't live in embedding space. So as retrieval systems matured, keyword matching came back into purview, not as a replacement for semantic search but as the natural complement.

Full text search is now available in Pinecone, in Public Preview. BM25 scoring across multiple text fields per index, Lucene query syntax, and multi-language tokenization are all built in.

A single index now holds text fields, dense vectors, sparse vectors, and filterable metadata, defined together in a schema set at index creation. Each text field takes a language setting that controls tokenization, stemming, and optional stop word removal. Stemming reduces words to their root form, so "running" and "runs" all match a query for "run." Eighteen languages are supported.

Multiple text fields can be configured per index, which removes the modeling workaround of routing every searchable string through a single field. Title, body, and tags can each be independent text fields, scored or filtered on their own terms.

Keyword search and vector search run in the same query against that schema. There is no separate keyword index to maintain, no results from two systems to reconcile.

Text match: text fields as filters

Text match filters narrow the candidate set by keyword logic before vector ranking runs. Three modes are supported: exact phrase, all tokens present, any token present. The vector search then operates only over documents that already satisfy the keyword condition.

Consider a legal document retrieval system. A lawyer searching for precedents needs two things: the document must contain a specific clause or citation verbatim, and among those, the most semantically relevant to their argument should rank highest. A text match filter handles the first condition, dense ranking handles the second, in a single query.

This composes with metadata filters too. A single query can require an exact phrase in a text field, filter on a date range, and rank by vector similarity.

What's supported in Public Preview

Upsert, fetch, and delete are supported for documents. Within a single query, scoring operates on one type at a time: BM25, dense, or sparse. For workloads that need to combine scores across modalities, the queries can be issued separately and merged client-side. Schema is fixed at index creation, which means existing indexes cannot be converted to use full text search until mutable schema lands.

Get started

Full text search is available now on under API version 2026-01.alpha. The documentation covers schema definition, query syntax, filter operators, and the Python SDK end to end. The Google Colab notebook has a runnable example using a Wikipedia dataset.

For a fuller walkthrough, this Bird Search demo combines full text search with multimodal vector search over ~2,079 North American bird Wikipedia articles, embedded with Gemini Embedding 2.

Original source

What Builder is designed for

I joined Pinecone six months ago to lead product-led growth. My focus: what it takes to go from building to scaling on the platform.

Talking to customers, I learned what they were building: legal research tools, medical search assistants, educational knowledge bases replacing scattered docs and whitepapers. Real products, with real users, doing real work.

What I heard consistently was that while the Starter tier is generous, free and capable enough to get a lot done, it started to feel tight past the prototype stage. The next available tier is Standard at $50/month, which is reasonable for teams already at scale, but hard to justify when your usage is still early and your workload generates nowhere near that every month. Having worked on developer tooling for close to a decade, much of it in open source, I recognized this friction immediately. Making powerful tooling accessible without surprising developers on cost was the job.

Builder is our attempt to fix that: a $20/month flat-rate plan designed for builders who've outgrown Starter, are ready to take their app to production, but haven't yet reached the scale that justifies Standard.

The limits on Builder are based on what we know about how thousands of builders at this stage actually work.

• 10 indexes keeps dev, staging, and production as separate environments without having to tear one down to spin up another.
• 1,000 namespaces per index lets you give each user or tenant an isolated space, which is usually what takes a product from internal tool to something shippable.
• 200 assistants per project supports document-heavy products where every user or use case gets its own context.
• More storage and usage headroom to scale comfortably at this stage.

Builder also includes free support, which tends to matter more than you'd expect the moment your users are real.

One note on availability: Builder runs on aws-us-east-1 now. Multi-region and multi-cloud support across AWS, GCP, and Azure are coming soon.

For the full breakdown, see the pricing page.

Which tier fits your stage

Builder fills a specific gap. Pinecone now has four tiers, each sized for a distinct stage of building, and Builder slots in between Starter and Standard.

Starter is free, and it's not a demo. With enough storage, indexes, and usage to build something real and take it pretty far. Most people who stay on Starter eventually need to create a second project, add a teammate, or create more indexes as their architecture evolves. That's the natural point where Starter starts to feel tight.

Builder is for when those ceilings start to matter. When you want to add a teammate, spin up another project, or build out an architecture that needs more indexes. Maybe it's a side project that picked up users faster than you expected. Maybe it's a startup product six weeks from launch. Maybe it's an internal tool your team depends on. Builder is sized for that stage: more indexes, more projects, more teammates, and a flat monthly cost that fits where you are.

Standard is for teams with established workloads who want to pay proportionally to scale. When you're there, usage-based pricing is the right call — and Standard is built for it.

Enterprise is for organizations with more complex requirements — dedicated infrastructure, advanced security and compliance, SLAs, and support built around how larger teams operate. If you're evaluating Pinecone at that level, reach out directly.

Available today

Builder is available now. Anyone who upgrades to Builder before May 31st gets their first month free — no code needed, applied automatically when you upgrade.

I believe infrastructure pricing should match the stage of building, not just the scale of it. Builder is our version of that to enable actively building, shipping, growing.

We've sized the limits based on what we know, and we'll keep adjusting as we learn how teams use the plan. If something specific isn't working for you, tell us! You can reach us at our Discord channel. Feedback is how this gets better.

Original source

A surprising amount of what your team knows is already written down. It's in the manual somebody put together last year, in the onboarding doc that gets passed around every time a new hire starts, in the thread where the tricky edge case finally got resolved, in the contract language your legal team has explained a hundred times. The knowledge exists. It's catalogued, stored, and searchable in theory.
But it doesn't help the person who needs it at the moment they need it.

So you answer the question. Again. And again. You find yourself reaching for the same Google Doc, pasting the same three paragraphs into Slack, saying some version of "we covered this in the handbook, let me find the section." The handbook has the answer. You have the answer. The person asking still can't get to it.

The part that's been broken

The tools that were supposed to solve this haven't. Enterprise search finds the document but leaves you to read the whole thing. Generic AI chatbots confidently make things up, or blend two policies together into an answer that sounds right but is wrong in a way you won't catch until it matters. Stuffing everything into a long context window works until the knowledge doesn't fit, or until the model can't tell which policy applies to which case, or until you realize you're spending too much burning tokens.
The other path is to build the pipeline yourself — hire the engineers, stand up retrieval, add evals, manage the refresh cycles, keep it running. Most in-house "ask our docs" projects stall out somewhere between the proof of concept and the version anyone actually uses, because the gap between retrieves relevant text and answers the question correctly turns out to be much larger than anyone expected. Plus, it keeps you from working on your core competency.
What's been missing is something in the middle: a way to put real knowledge behind an application without needing engineers to build and maintain the pipeline, and without it going off the rails the first time someone asks a question that requires more than copying a paragraph back.
Knowledge, as we use the term, is the curated, situated content your team actually operates on — policies, contracts, runbooks, tickets, the resolution to last month's weird edge case — together with the context that makes it usable: what's current, what supersedes what, which version applies in which situation. The difference between a system of record (what your data warehouse stores) and a system of knowledge (what your team actually knows). Not the model's training data. Not a pile of retrieved chunks the application has to stitch back together.

What Marketplace actually does

It starts with a template. Pick one for the kind of application you want — customer support, legal search, sales enablement, onboarding, or something else — and point it at the knowledge it should use. A folder in Google Drive, a stack of PDFs, a wiki, a set of tickets. Marketplace ingests everything, and a few minutes later you have something your team can start asking questions of.
Answers come with receipts. The system responds in full sentences, with citations that point back to the specific documents the answer came from. You can see what it knows — and what it doesn't, which turns out to be almost as important. When a question falls outside its scope, it says so instead of inventing an answer to be helpful. When answering a question requires pulling from more than one document — a contract clause that interacts with a policy, a support issue that touches two different product areas — it reasons through the connection instead of stitching together unrelated fragments. That stitching is the failure mode that makes most AI answers untrustworthy. (More on how that works here.)
Publishing is one click. Once the application is live, your team accesses it as a web app at a URL. Gate access with single sign-on, open it to a whole department, or share it with partner outside your organization. The same knowledge layer can also serve the AI agents your company is starting to deploy — so agents answer from the same vetted sources your team does, and every improvement to the knowledge base benefits both. The work you put into Marketplace compounds over time.

Why it's different

Three things matter for the knowledge worker deciding whether to trust this with real work.
Every answer traces back to a source. Not a vague gesture at "the knowledge base," but a specific citation to a specific document. If the application tells a new hire how your refund policy works, they can click through and read the actual policy. This is what makes the answers trustworthy, and it's what makes the system useful for anything that has real consequences.
It's honest about its edges. The system knows what it knows, and it's built to say so when a question falls outside that scope. The worst failure mode in an AI tool isn't being wrong; it's being confidently wrong about something the reader can't verify. Marketplace is designed to fail loudly and truthfully, not quietly and confidently.
You don't need an engineering team to run it. This is the part that has blocked most knowledge workers from solving this problem themselves. Marketplace handles the infrastructure — the ingestion, the updating, the versioning, the scaling — so the work you do is the work you already know how to do: decide what knowledge should be in there, write the occasional clarifying note, review the questions people are asking. You stay focused on the work you do best. The system does the parts that were never your job in the first place.

Where you take it

Start small. Pick one corner of your team's knowledge that people keep asking about, stand up an application for it, see if it changes the shape of your week. If it does, the same foundation scales — to more of your team's knowledge, to more teams in your organization, to applications you share with customers and partners, and eventually to the AI agents that will be asking questions on behalf of people who haven't even joined yet.
The line between "knowledge for people" and "knowledge for agents" is thinner than it looks, and the thing you build here works on both sides of it.

Getting started

Free on Starter — 1M input tokens/month through June 30 (2x the usual) so you can test it on real workloads.
Setup is three steps and takes about as long as writing the email that announces it.

1. Pick a template. Customer support, legal search, sales enablement, onboarding, internal IT, or a blank starting point. Each template ships with a tuned prompt, a recommended schema, and defaults that match the shape of the problem.
2. Connect your sources. Google Drive folders, PDF uploads, wiki exports, ticket exports. Marketplace handles chunking, embedding, and indexing. Re-indexing on source changes is automatic.
3. Publish. One click, a branded interface, SSO-gated, shareable internally or externally. Connect to agents through the same endpoint when you're ready.

Marketplace is available now as a web application. Start at marketplace.pinecone.io.

Original source

Plus new Pinecone Marketplace, Builder tier, full-text search, and regions

The Primary User Is Changing

Every technological paradigm shift produces a defining data infrastructure category. Relational databases for client-server. Object stores for clouds. Vector databases for Assistive AI.

Pinecone built the market-leading vector database. 800,000+ active developers and 9,000+ paying customers run their AI on it: semantic search, recommendation systems, retrieval-augmented generation. We defined the category.

That Assistive AI category was built for a human user; type a query, get relevant documents back. It worked.

Now agents are surpassing humans as the primary consumers of knowledge infrastructure. In this Agentic AI era, agents are performing tasks, stuck in brute-force loops. Retrieve a set of chunks. Read them. Realize something is missing. Retrieve more. Synthesize. Hit a conflict. Retrieve again. Roughly 85% of an agent’s effort is spent on knowledge retrieval and the output still requires human review before anyone can act on it.

The inevitable result: task completion rates stuck at 50–60%. Unpredictable latency that kills production SLOs. Outputs no enterprise can govern. And, downstream of all of it, runaway token costs. This is the “ten blue links” era of agentic retrieval.

Web search already made the transition from ranked links to direct answers. Knowledge infrastructure needs the same leap. The Pinecone vector database is the foundation; vector primitives and their management remain essential. But the retrieval patterns agents need are fundamentally different from what humans need. That is what changed.

The agentic era needs something different.

Introducing Pinecone Nexus

Pinecone Nexus is a knowledge engine, not a retrieval system. The distinction matters.

A retrieval system finds documents and hands them to a frontier model at inference time. The model burns tokens sifting through raw content, introduces latency, and risks hallucination. This is reasoning at the retrieval stage. It is fragile, slow, and expensive.

Nexus moves the reasoning upstream, from retrieval to knowledge compilation. It structures, contextualizes, and composes specialized contexts (derived artifacts) before the agent needs them. The agent receives trusted knowledge in a context-specific structured format, not raw documents. It completes the task, not the retrieval. Frontier models are freed to do what they were designed for — intelligent reasoning, not managing knowledge.

With Nexus, governance is built into the knowledge engine. Context is assembled dynamically per task, scoped to RBAC permissions, and free of context-rot. Every artifact is versioned — every answer traces back to its source data and transformations. PII is tagged at ingest with centralized rules governing how LLMs process it. Token consumption is managed across users and workloads in one place, and a unified dashboard provides real-time visibility into usage, spend, and compliance.

Nexus has two core components: a context compiler and a composable retriever. The context compiler builds and organizes knowledge around how your company operates. The composable retriever formats and serves responses precisely for how each agent needs knowledge to complete its task.

The context compiler is the heart of the shift. Give it source data and a task spec. It compiles raw data into task-optimized specialized contexts. These contexts include newly-derived artifacts — the concrete form of information an AI agent acts on. Purpose-built for accuracy and speed, agents consume these artifacts directly. Unlike a traditional compiler, it is iterative: it experiments with representations, evaluates them against the task, and converges on the precise knowledge structure the agent needs. The work that used to happen at inference time, burning tokens and producing ambiguous results, now happens once at compilation time — and gets better with every iteration.

Take a mid-market SaaS company. Its data lives in a data warehouse, Salesforce, Slack, Gong, Gmail, Jira, Google Drive.

The current approach: point a vibe coding tool at all the sources and unleash it to perform the task. It scans everything, retrieves what it can, and hopes the right context surfaces. Sometimes it works. Often it hallucinates, misses critical connections, or drowns in irrelevant data.

The context compiler works differently. It reads the same underlying data but builds specialized context artifacts for each agent's task:

A Sales Agent gets deal context — Gong transcripts synthesized with opportunity stages, champion email threads, and competitive mentions from Slack. Not a CRM lookup. A picture of the deal.

A Finance Agent gets revenue context — contract terms linked to billing schedules, usage thresholds, and expansion signals. Same Salesforce record, completely different artifact.

A Marketing Agent gets attribution context — campaign touches connected to win/loss themes from Gong and product-qualified signals from usage data. What's actually driving conversion, not what the CRM says sourced the lead.

A CEO Agent gets a cross-functional signal — ARR movement linked to customer health, hiring velocity, and product milestones. Same systems. Entirely different synthesis.

One data estate. Four agents. Four distinct artifacts; each optimized for task completion, not generic retrieval.

That's the difference between a system of record and a system of knowledge. The system of record stores what happened. The context compiler does not organize your data; it builds what each agent needs to understand about your business — differently for every agent, every task. Re-used every time.

The composable retriever serves these curated artifacts at query time: low-latency, grounded, composable across sources. Typed fields. Per-field citations with confidence levels. Deterministic conflict resolution. Output shaped exactly as the agent specified, structured to complete the task accurately and fast.

The result: higher task completion rates, faster time-to-completion, grounded outputs, and up to 90% reduction in token usage. This is a structural shift by offloading the reasoning to a dedicated knowledge layer instead of every inference call.

For AI agents to have a tangible impact, they need a seamless and secure way to work within your business. This means giving agents the necessary context found in the content organizations rely on daily - from product roadmaps and research to marketing assets and countless other file types. By securely integrating the decades of enterprise content that Box manages with Pinecone Nexus' Knowledge Engine, we're giving AI agents the context they need to deliver more accurate and efficient results – Tamar Bercovici, VP of Engineering at Box.

Enterprise AI lives or dies on the quality of the data feeding it. The hardest part has always been transforming the messy, document-heavy reality of enterprise content into something agents can actually reason over — and 87% of the Fortune 1000 trust Unstructured to do exactly that. Connecting Unstructured’s ingestion and preprocessing platform to Pinecone Nexus closes the gap between raw enterprise data and the trusted, task-specific knowledge agents need. Together, we’re turning every organization’s unstructured data into a knowledge asset that compounds with every agent interaction. – Brian Raymond, CEO of Unstructured

KnowQL: A Declarative Query Language for Agents

Agents cannot express what they need today. This is a structural gap, not a feature gap.

Every team building an agentic application re-implements the same retrieval logic from scratch. Custom tool definitions. Bespoke glue code between agent frameworks and data sources. One-off integrations that break when anything changes. There is no shared vocabulary for what agents want from a knowledge system.

We have seen this before. Before SQL, every application built its own data access layer. SQL gave relational databases a universal interface and made an entire ecosystem of applications possible on top of them. The standard interface changed everything.

Agents face the same structural moment. And there are things they literally cannot say today:

“Return the answer, not twenty chunks.” No output shape contract. Agents get raw text and re-parse every call. More token burn.

“Cite which source, with confidence.” No field-level grounding. Agents cannot separate facts from guesses. Unreliable, ungoverned answers.

“Standard depth, under 500 milliseconds.” No budget envelope. Every call runs however deep, however long. Unpredictable, slow, wasteful.

KnowQL gives agents the vocabulary they are missing. Six core primitives: intent, filter, provenance, output shape, confidence, and budget, in a single declarative interface that returns trusted knowledge — structured, precise, and grounded. Composable across the heterogeneous knowledge sources that real enterprise AI requires.

Building reliable, long-horizon agents is fundamentally a context engineering problem. Getting the right information to the agent in the right format is what separates demos from production. Pinecone Nexus solves that at the knowledge layer, and KnowQL is the standard interface the agentic ecosystem has been waiting for. That's why LangChain is collaborating with Pinecone to advance it. And as teams build agents with Nexus, LangSmith gives them the observability and evals to help them move through the agent improvement loop. – Harrison Chase, CEO of LangChain

Enterprises win with agentic AI when their agents can reason over the full landscape of trusted business data. Teradata is partnering with Pinecone on KnowQL and Knowledge engine, giving the world's most demanding organizations a clear path from governed data to autonomous, accurate, agent-driven outcomes — backed by the scale and trust enterprises have built on Teradata. – Sumeet Arora, Chief Product Officer, Teradata

Early access for Pinecone Nexus and KnowQL is open now to customers and partners building agent-native applications in financial services, healthcare, legal, enterprise SaaS, and any domain where agents reason over complex, proprietary knowledge.

What Pinecone Nexus & KnowQL Make Possible

Knowledge Artifact Curation

The context compiler produces persistent, durable knowledge representations that maintain context across sessions, users, and workflows. Not ephemeral retrieval results but rather curated artifacts that compound over time. This becomes the system of knowledge for the organization.

Autonomous Query Planning

An embedded agent builds and refines ingestion and retrieval pipelines purpose-built for each task. The pipeline adapts to the context, not the other way around.

Governed Reasoning at Scale

Native hybrid retrieval, vector and full-text unified, delivering semantic breadth with exact-match precision at agent query volumes. Per-field citations, confidence scores, and ACL-aware filtering make every answer auditable and policy-safe by default.

Composable Retrieval with KnowQL

Agents compose knowledge access on demand using the six KnowQL primitives. Vertical AI applications become buildable without custom retrieval infrastructure for every deployment.

Measured impact: Task completion rates above 90%. 30x faster time-to-completion. Measurably improved precision and relevance, with every answer cited, scored, and auditable. And up to 90% less token spend on top of it. This changes the ROI equation for enterprise AI.

Dive Deeper into Pinecone Nexus

Pinecone Marketplace: From Pinecone Nexus to Production in Minutes

Pinecone Nexus gives agents trusted knowledge. Pinecone Marketplace gives teams the fastest path to production.

Most teams spend more time assembling ingestion, embedding, retrieval, and orchestration plumbing than building the applications that make them unique. Marketplace eliminates that with production-ready knowledge applications, built by Pinecone and partners, deployable and customizable in minutes. No infrastructure assembly required.

These are not demos. Every solution in the Marketplace addresses a problem our customers are actively building for.

Launch-day solutions:

Pinecone Marketplace launches with more than 90 knowledge applications across the following categories and more:

Sales & Revenue

Equip reps with instant answers on product, pricing, and competitive positioning. Streamline deal approvals, discount exceptions, and contract decisions — all grounded in your internal knowledge.

Insurance

End-to-end apps for underwriting, claims, fraud, policy servicing, and compliance. Purpose-built for the document-heavy workflows that define every role in the insurance value chain.

Real Estate

Cover the full CRE lifecycle, from acquisitions diligence and development to leasing, asset management, and property operations. Purpose-built for the deal teams and operators who move markets.

Legal & Compliance

Apps for M&A diligence, employment law, data privacy, immigration, and legal document search. Scoped to specific practice areas so every answer is grounded in the right sources.

People & HR

Make benefits self-service and onboarding effortless. Deploy knowledge applications that guide employees through HR policies, training, and internal tools from day one.

Customer Support

From frontline Q&A to Tier-3 escalations and executive complaint handling, resolve issues faster and surface customer signal that feeds directly into product and CX strategy.

Free at launch. Partner-built commercial solutions coming soon. Built to be modified, extended, and taken to production.

2026 is the year agents move from workflows to employees — and the bottleneck is no longer the model, it's getting agents grounded in the right knowledge. We're excited to bring LlamaParse's document ingestion and parsing into Pinecone Nexus and the Pinecone Marketplace. Teams can now go from messy documents with complex layouts, tables, handwriting, and images to trusted knowledge ready for agents to act on — whether they're shipping a Marketplace app or building on Nexus directly. – Jerry Liu, CEO of LlamaIndex

Enterprise AI only delivers when it shows up inside the workflows teams actually rely on. ThoughtFocus is partnering with Pinecone on two fronts: building production-ready knowledge applications on the Pinecone Marketplace for our clients, and deploying those same applications inside ThoughtFocus to accelerate how our own teams work every day. The Marketplace gives services partners like us a way to package deep domain expertise into customer-ready apps — and to prove the model on ourselves first. This is how enterprise AI moves from pilots to production. — Nick Sharma, CEO of ThoughtFocus

Removing the Barrier to Build

The best knowledge infrastructure on the market should be accessible to every builder, at every stage. We restructured pricing to make that real.

Builder Tier — $20/Month

Full access to Pinecone’s production-grade infrastructure for developers and small teams. No degraded performance. Flat, predictable cost. No surprise bills. Free support. The same Pinecone that enterprises run mission-critical workloads on, now at a price that removes the barrier for any serious builder.

Dedicated Read Nodes

On-Demand works exactly as designed for variable, unpredictable workloads. As retrieval scales — sustained high volume, tight latency SLO’s, finance asking for predictable spend — fixed pricing becomes necessary. Dedicated Read Nodes (DRN) gives you dedicated, provisioned read capacity with a warm data path. Vectors stay hot. No cold starts. No rate limits. Fixed hourly per-node pricing. Production workloads see 77–97% cost reduction at scale.

Bring Your Own Cloud

For organizations with data residency requirements, regulatory constraints or existing cloud commitments, BYOC deploys Pinecone fully managed within your cloud environment. Complete data control that includes Pinecone Nexus very soon, with the simplicity of a managed service.

Builder tier at $20/month, DRN, and BYOC for the largest enterprises exist for the same reason: infrastructure should enable ambition, not constrain it.

The Full Stack

Today’s announcements are new components of Pinecone’s knowledge platform:

LAYER | PRODUCT | WHAT IT DOES

Access Layer | Pinecone MarketplaceNew | Production-ready knowledge applications. Deploy in minutes. No infrastructure assembly required.

Knowledge Engine | Pinecone Nexus + KnowQL New | Transforms organization data into trusted, persistent, queryable knowledge for agents. KnowQL is the declarative query language for the agentic era.

Foundation | Pinecone Database | Native hybrid retrieval with full-text searchNew. BYOC. DRN. Builder tierNew at $20/mo. The most performant and affordable vector database in the market.

Based on years of partnering with our users to build knowledge retrieval systems and the real-world demands we uncovered developing Pinecone Nexus, we integrated native full-text search into the core Pinecone Database. This ensures the stack handles the unique economic and technical demands of agent-scale query volumes. We will continue to evolve the core database based on these Nexus workloads, ensuring our infrastructure is purpose-built for the speed of autonomous AI.

What Comes Next

We pioneered the vector database and defined RAG as a standard pattern. Those contributions are embedded in AI infrastructure today. Our continuous research and engineering innovation enables us to lower prices so that both the solo builder and the largest global enterprise can build on Pinecone.

What is unique to every organization, and what did not exist until today, is a knowledge engine that moves reasoning from retrieval to curation. A declarative query language that gives agents the vocabulary they have been missing. Infrastructure architected for agentic systems operating at orders of magnitude beyond human scale.

The companies that will define their industries over the next decade are building agents that operate on trusted knowledge. They are discovering that the limits they thought were intrinsic — limited expert bandwidth, slow decision cycles, high cost per unit of insight — were infrastructure problems waiting to be solved.

Solve the infrastructure problem. The transformation follows.

Our mission: make AI knowledgeable.

Today we’re taking the largest step yet toward what that means at agent scale.

For a category-level walkthrough of what a knowledge engine is, how one works, and how it compares to RAG, vector databases, and semantic layers, see our /learn/ piece on how a knowledge engine works.

START HERE

May 4 : Pinecone Nexus & KnowQL Early Access is open → Apply

May 5 : Pinecone Marketplace is live → Explore

May 6 : Builder tier is $20/month → Start building

May 7 : Native full-text search is in Public Preview → Try it out

May 8 : New regions: AWS eu-central-1 (Germany) and AWS ap-southeast-1 (Singapore) → Get started

Original source

Pinecone Dedicated Read Nodes (DRN) are now generally available. For the full story on what DRN is and why it matters, read Pinecone Dedicated Read Nodes: Now Generally Available.

DRN gives teams running revenue-critical systems a clear path to consistent low-latency retrieval under sustained load with predictable cost scaling. But once you ship to production, new questions surface: How do I know if I'm over-provisioned? How do I keep multi-tenant workloads isolated? Can I hit a latency target by trading off recall? Without answers, teams either over-spend on capacity they don't need or under-provision and risk latency spikes that hurt conversion.

DRN answers those questions with four new capabilities that give teams deeper control and better observability.

TL;DR

With GA, DRN adds four new production capabilities:

• Configurable performance vs. recall per query
• Metrics exporting for CPU visibility and external observability
• A web console experience for day-2 operations
• Multi-namespace support — early access

1) Configurable performance versus recall, per query

Not every query needs maximum recall. Some queries require high throughput at cost.

Interactive experiences often require a hard latency budget. Batch jobs may prefer higher recall even if they run slower. Until now, Pinecone has always executed queries at maximum recall.

With GA, DRN adds two query-time parameters:

• max_candidates: an integer cap on how many candidate vectors the search considers
• scan_factor: a float from 0.5 to 4.0 that controls how much of the index Pinecone scans

You can now trade recall for speed per query without changing your index.

A simple mental model:

• Lower scan_factor scans less of the index, improving throughput and latency, but can lower recall.
• Higher scan_factor scans more, improving recall, but costs more to compute.

Backwards compatibility stays intact. If you omit these parameters, Pinecone preserves current behavior and runs at maximum recall.

2) Metrics exporting for production observability

You can't run a dedicated serving tier as a black box. You need to answer:

• Am I CPU-bound, or over-provisioned?
• Do I have a hotspot on one shard?
• Should I add replicas, add shards, or switch node type?

With GA, we’ve added CPU utilization visibility for DRN, exposed at the shard level and index level, available:

• In the Pinecone console for quick diagnosis
• Via the metrics export endpoint for integration with your observability stack

3) Web console experience for day-2 operations

With GA, we’ve added a first-class DRN experience in the Pinecone web console. You can:

• See dedicated capacity configuration (shards, replicas, node type)
• Track readiness and scaling operations
• View key performance and capacity signals, including CPU utilization

4) Multi-namespace support — early access

Many production architectures use namespaces for multi-tenant isolation. DRN previously supported one namespace per index, which created friction for platforms and ISVs.

DRN’s multi-namespace support (in early access), enables:

• Multi-tenant DRN indexes without forcing one index per tenant
• Better fit for workloads where tenant sizes vary
• A smoother path from On-Demand multi-namespace patterns into DRN without redesign

Multi-namespace indexes will be fully supported in DRN soon. Currently, they are available in early access. So, if you’d like multi-namespace indexes for DRN to be enabled, contact your account rep or file a support ticket in the Pinecone console.

Get started

Running vector retrieval in production means answering hard questions about cost, latency, and isolation. These four capabilities give you the configurability and visibility to answer them confidently.

DRN is now generally available and includes these new capabilities. Create a DRN index to get started, or read the DRN documentation for configuration details, scaling guidance, and API reference.

Original source

Vector workloads aren't one-size-fits-all. Some applications, such as RAG systems, agents, prototypes, and scheduled jobs, have bursty, variable traffic. They spike, they idle, they spike again. Pinecone's On-Demand service is built for exactly this: elastic, usage-based, and cost-effective when query volume is unpredictable.

But when retrieval is both revenue-critical and consistently running at scale, the requirements change. Query volume is high and sustained, latency SLOs are tight, finance needs a number they can forecast, and per-request pricing stops being your friend. The cost curve steepens. Rate limits constrain throughput. And the question shifts from “does retrieval work?” to “can we run it affordably and predictably at this scale?”

Today, we're announcing Pinecone Dedicated Read Nodes (DRN) is generally available. DRN indexes are designed for workloads that need predictable performance, high throughput, and cost-efficient scaling under sustained load.

TL;DR

If you run search, recommendations, or agents with sustained, high-volume traffic, DRN gives you:

• Lower, more predictable cost with fixed hourly per-node pricing that is significantly more cost-effective than per-request pricing for high-QPS workloads and easier to forecast
• Predictable low-latency and high throughput through dedicated, provisioned read nodes with a warm data path (memory + local SSD) that keeps your vectors always hot, no cold start latency regressions
• Scaling that matches production traffic, via replicas for QPS and shards for storage, no rate limits constraining your throughput
• A single API call migration path from On-Demand with no reindexing, no downtime, and no code changes
• 77-97% cost reduction on real production workloads. See the examples below.

And with GA, DRN adds four new production capabilities for deeper control and observability. Read more about DRN's new GA capabilities here: Four New GA Features for Dedicated Read Nodes That Give Teams More Control and Observability.

Use the Pincone Assistant below to ask questions about Pinecone Dedicated Read Nodes – from use cases and scaling to cost model and migration. Or skip the assistant and read the rest of the blog post.

When revenue-critical retrieval consistently runs at scale, the economics change

Most teams don't fail because vector search “doesn't work.” Teams hit a different wall: retrieval is part of an end-user experience that drives revenue, and the economics and performance of that retrieval need to be as reliable as any other piece of critical infrastructure.

In practice, three things tend to happen at once as workloads scale:

• Per-request costs climb at sustained QPS. On-Demand's usage-based pricing is efficient for variable demand. But when volume is consistently high, costs scale with every query, especially when scanning large datasets. What was cost-effective at moderate traffic becomes expensive at sustained scale.
• Cost becomes hard to forecast. When pricing is per-request and volume fluctuates even modestly, forecasting spend requires assumptions. Finance wants a number. You can only offer a range.
• Rate limits constrain throughput. Multi-tenant serverless systems use rate limits to ensure quality of service across all users. That's good system design. For workloads that need thousands of queries per second without interruption, those limits become a ceiling you can't control.

At sustained scale, these tradeoffs carry real business consequences, especially when retrieval is revenue-critical:

• Hard-to-forecast spend from a request-driven cost curve at high, steady QPS
• Throughput ceilings from rate limits that can't flex with your traffic
• Slower product velocity when engineers work around limits instead of building features

DRN is built for workloads where retrieval performance and economics need to be planned and provisioned, not variable.

What workloads are a fit for DRN?

Choose DRN when your workload has:

• Consistent or high QPS: Hourly per-node pricing beats per-request pricing, often significantly
• Large vector counts: Hundreds of millions to billions of vectors benefit from DRN's always-hot data path, with indexes kept in memory and on local SSD, so there are no cold start latency regressions
• Tight latency SLOs: Dedicated resources give you a performance floor you control
• Predictable spend requirements: Fixed hourly pricing makes forecasting straightforward

On-Demand is the right fit for:

• Bursty or variable workloads: Elastic scaling and per-request pricing are more efficient
• Dev/test environments and prototypes: Lower cost, zero provisioning
• Workloads with many small namespaces: On-Demand's low latency and effortless scaling shine here

DRN is configured per-index. So you can run dev/test workloads on On-Demand and production workloads on DRN. Same platform, same APIs. Pinecone uniquely lets you mix these performance profiles within a single platform.

Customer story: how ZoomInfo scaled real-time recommendations (and kept costs predictable)

ZoomInfo builds go-to-market intelligence software that helps sales and marketing teams identify the right people and companies to engage. Their Applied AI team built a real-time contact recommendation system that required accurate, low-latency vector search over more than 390 million contact embeddings, with interactive UI expectations.

Pinecone became the foundation of their recommendation system. As traffic grew, Dedicated Read Nodes provided a straightforward way to isolate and scale reads with predictable performance and cost, without adding ops-heavy scaling, management, and tuning.

“Pinecone’s slab architecture and Dedicated Read Nodes gave us the speed, consistency, and isolation we needed to run real-time recommendations at scale. Instead of managing infrastructure, we spend our time improving our recommendation model and the product itself. That has reduced the time our customers spend researching, filtering, and evaluating contacts—from hours to minutes—by giving them the right people to reach out to with a single click.” — Carlos Nunez, Vice President of Engineering and Applied AI at ZoomInfo

In practice, DRN gave ZoomInfo predictable performance and cost-efficient scaling, while keeping the workflow simple to operate. So engineers could stay focused on model and product improvements rather than infrastructure management.

Read the ZoomInfo case study.

DRN in production: cost and performance across real workloads

The economics of DRN depend on the shape of your workload. Below are three production workloads that illustrate where DRN makes a big difference.

Billion-scale vector search: 77% cost reduction

A major music licensing marketplace runs semantic search over a catalog of 1 billion vectors in a single namespace. Query volume is low at ~8 QPS, but the dataset is large enough that per-request pricing adds up fast, because every query scans a massive index.

On DRN, this workload runs on T1 nodes with 14 shards and 1 read replica. Latency is tight: 31ms p50, 39ms p99. This workload costs 77% less to run on DRN.

The takeaway: even at low QPS, large vector counts drive meaningful savings on DRN because the cost scales with provisioned infrastructure, not per-query scans over a billion-vector index.

Low-latency search: 83% cost reduction

A global enterprise networking company uses Pinecone for search across a 6.1 million vector index at 20-50 QPS. The workload is small in vector count but latency-sensitive, and the consistent query volume makes per-request pricing expensive relative to the dataset size.

On DRN, this workload runs on T1 nodes with 2 shards and 2 read replicas. They achieve 12ms p50 and 45ms p99. This workload costs 83% less to run on DRN.

The takeaway: DRN's dedicated resources deliver a latency floor you control. When your SLOs are tight and traffic is steady, provisioned capacity is both faster and cheaper than paying per request.

High-QPS search: 97% cost reduction

A major academic and scientific publishing platform runs sustained search traffic at 200-270 QPS across a 14 million vector index. This is the workload profile where per-request pricing diverges most sharply from provisioned pricing: moderate-to-large dataset, high and consistent query volume.

On DRN, this workload runs on T1 nodes with 1 shard and 4 read replicas. They hit 45ms p50 and 91ms p99. This workload costs 97% less to run on DRN.

The takeaway: at sustained high QPS, DRN's fixed hourly pricing delivers a dramatic cost advantage. Replicas scale throughput near-linearly, so you add capacity in proportion to query volume rather than paying per request at every step.

DRN is now GA

Dedicated Read Nodes gives your index a dedicated serving layer for reads while keeping everything else the same.

You keep:

• The same Pinecone APIs and SDKs
• The same write pipeline
• The same operational model for your index lifecycle

You add:

• Dedicated, provisioned read capacity per index
• A warm data path, with data always kept in memory and on local SSD
• No read rate limits, dedicated resources mean you control your throughput ceiling

You scale DRN in two dimensions:

• Replicas scale throughput and availability. Add replicas to increase QPS near-linearly.
• Shards scale storage. Add shards to grow capacity in fixed increments.

And because DRN is configured per-index, your dev/test indexes can stay on On-Demand while production indexes get dedicated resources. Same architecture, same APIs, same behavior, different cost and performance profiles where you need them.

DRN lets you keep Pinecone's simple developer experience while making read performance and costs predictable at production scale.

Four new GA features for deeper control and observability

DRN's core value stays the same: dedicated resources, always-hot data, and fixed-cost scaling. GA adds four capabilities that improve control and observability for day-2 operations: configurable performance vs. recall per query, metrics exporting for observability, a web console experience, and multi-namespace support (in early access).

Read more about DRN's new GA capabilities here: Four New GA Features for Dedicated Read Nodes That Give Teams More Control and Observability.

Make revenue-critical retrieval predictable at scale

The most expensive time to fix retrieval infrastructure is after users already depend on it. By then, every cost surprise has a real consequence: budget overruns trigger hard conversations, throughput ceilings slow product launches, and engineers spend time working around limits instead of building features.

Dedicated Read Nodes, now generally available, gives teams running revenue-critical retrieval at sustained scale a clean path to predictability: dedicated read capacity with always-hot data, no read rate limits, and fixed hourly pricing that scales with your infrastructure, not your query count.

Create a DRN index to get started, or read the DRN documentation for configuration details, scaling guidance, and API reference.

Original source