Pinecone makes full-text search generally available alongside vector retrieval

Pinecone has made full-text search generally available, combining keyword ranking and text filters with vector fields in one index. The release targets retrieval tasks where exact identifiers matter. Current documentation sets out API requirements and important limits, including schema planning, separately supplied embeddings and the distinction between filtering and ranking.

Pinecone announced general availability of full-text search on 9 September, adding keyword ranking and text-match filters alongside vector retrieval in its database. The dated announcement targets a familiar weakness in AI retrieval: a result can be semantically similar to a question while still referring to the wrong identifier.

The release brings BM25 ranking, Lucene-style queries and text filtering into an index that can also contain dense and sparse vectors. Pinecone positions this as a way to reduce the need for a separate text-search service. It says usage-based capacity uses the existing read-unit and write-unit framework, with provisioned capacity and bring-your-own-cloud options also available.

For an AI application, the meaningful question is not whether keyword search is newer than vector search. It is whether the retrieval system can express the constraints the task actually requires. A catalogue lookup and an open-ended research question should not automatically receive the same matching strategy.

Matching and ranking are different decisions

The current full-text search documentation says a request chooses one scoring type. A text filter can first narrow the eligible documents, after which vector similarity ranks the survivors. Alternatively, an application can run separate searches and combine their results. Having several field types in one index does not mean every request automatically blends every ranking signal.

The same guide requires API version 2026-07, or the corresponding Python SDK version ten or later. Document-shaped indexes require supplied vector values rather than integrated inference fields. Schema changes are not currently supported after index creation. Those are concrete planning constraints for teams moving an existing retrieval pipeline to the Documents API.

In our assessment, this makes schema design part of the rollout rather than a detail to postpone. Decide which fields need literal matching, which hold prose and which represent access boundaries before building the index. An experiment that omits those distinctions may demonstrate an appealing search box without demonstrating a dependable production workflow.

Text processing changes what an exact match means

Pinecone’s architecture explanation describes its use of the Tantivy text-search library and the relationship between vector ordering and text storage. It distinguishes phrase filters from requirements that all or any tokens appear. It also explains that filtering determines eligibility, while scoring determines order.

That distinction is easy to lose in an AI demonstration. If a user asks for documentation about one component, finding related components may be actively unhelpful. The application needs to decide whether the component identifier is a hard condition or merely another ranking hint. A language model generating the query does not remove that design decision.

The text-processing reference provides a separate place to check tokenisation and field settings. Developers should test their own punctuation, identifiers and languages against the configured analyser. Treat a phrase-level match as an explicitly configured retrieval behaviour, not as a blanket promise that arbitrary strings will always be compared byte for byte.

A release label is not a migration recipe

There is a documentation detail worth noticing: the older architecture article still contains preview-era examples and wording, while the current overview specifies the newer API. Its discussion of design remains useful background, but copying an old snippet without checking the current reference can lead to an avoidable integration mismatch. The dated general-availability post is the news source; the current reference is the implementation source.

Teams can make this distinction visible in their evaluation notes. Record the API version, SDK version and index schema next to each test result. That way, a later failure can be investigated against a known configuration rather than a screenshot of an answer that happened to look right.

A small test collection can be more revealing than a large undifferentiated benchmark. Include near-identical part numbers, a phrase that must remain adjacent, a question expressed using different words and a document that should be excluded by an access rule. The expected result should be written down before running the query. Otherwise it is too easy to rationalise whichever answer the system returns.

Better retrieval still needs an accountable application

Our assessment is that the release broadens the choices available to developers rather than eliminating their responsibility for relevance. Search quality should be measured at the point where the application uses the retrieved material. A high-ranking result can still be outdated, incomplete or unsuitable for the user’s task.

For retrieval-augmented generation, inspect both the selected documents and the resulting answer. Keep examples where the system should return no useful match. An assistant that recognises missing evidence can be safer and more useful than one that confidently fills the gap with a nearby document.

Pinecone’s announcement gives teams a unified place to test lexical and semantic retrieval. The strongest case for adoption will be a measurable improvement on the queries their current system mishandles, with the operational costs and migration constraints included in the comparison against the existing production baseline.