01
Overview
Pinecone Full-Text Search is now generally available in Pinecone Database, giving developers a native way to combine exact keyword retrieval with the semantic search Pinecone is known for. The GA release adds BM25 ranking across multiple text fields, Lucene query syntax, fuzzy matching, text-match filters, and language-aware tokenization and stemming for 18 languages. The important change is architectural: text fields, dense vectors, sparse vectors and metadata can live in the same document schema and index, so a RAG system or agent does not need a separate lexical-search cluster just to handle exact identifiers.
02
Why Pinecone added full-text search
Embedding search is strong when wording differs but meaning is similar. It is weaker when the query itself is the answer key: a SKU, order number, legal citation, error code or exact phrase. Pinecone gives the example of a product identifier such as PROD-001. A vector search may rank visually or semantically similar identifiers nearby even when the user needs an exact match. That failure can be silent because nearest-neighbor search will still return something.
Full-text search addresses that class of query with lexical retrieval. BM25 scores actual terms, while text-match filters can require a phrase or token condition before semantic ranking runs. For agentic systems, this matters because a wrong lookup early in a tool chain can contaminate every step that follows.
03
What is included in the GA release
Pinecone says Full-Text Search now supports BM25 keyword ranking across multiple text fields, Lucene query syntax, boolean and phrase queries, fuzzy matching with the tilde operator, tokenization and stemming in 18 languages, and text-match filters that can restrict a semantic search to records meeting a lexical condition. A single index can contain text fields alongside dense vectors, sparse vectors and metadata.
That allows several retrieval patterns. A pure keyword query can rank documents by BM25. A semantic query can first be constrained by a text-match filter and then rank the remaining candidates by vector similarity. A system can also keep structured metadata filters in the same query path.
04
Full-text search vs semantic search
The two methods solve different jobs. Semantic search is best when a user asks for concepts, paraphrases or broad meaning. Full-text search is best when literal wording matters. In many production RAG systems, the right architecture is not to choose one permanently but to route or combine them according to the query.
Use full-text search when the user supplies exact identifiers, quoted phrases, names, codes or other literal strings. Use dense retrieval when the user describes an idea in different language from the source material. Use a text-match filter plus dense ranking when a hard lexical constraint must be satisfied before semantic relevance decides the order.
05
Why this matters for RAG and agents
RAG systems often fail in retrieval rather than generation. If the retriever returns the wrong policy, order or error-code documentation, even a strong language model can answer confidently from bad context. Pinecone's GA release targets this precision gap without forcing teams to operate a second search engine solely for lexical matching.
For agents, exact lookup is even more important. An agent may extract an order ID in one step and use it in the next. Full-text retrieval can enforce that literal value rather than returning a similar-looking record. This makes the retrieval layer more useful for support workflows, product catalogs, legal research and structured operational tools.
06
Pricing and availability
Pinecone lists dense, sparse and full-text indexes on its Starter plan and above. The Starter tier is free and includes limited monthly storage and read/write usage. The Builder tier is currently $20 per month. Standard has a $50 monthly minimum applied to usage, while Enterprise starts with a $500 monthly minimum. Exact database costs depend on storage, read units, write units, cloud, region and deployment model.
Pinecone says full-text indexes use the same usage-based capacity model as its vector indexes. That means there is not a single universal 'price per full-text query' that applies to every workload. For on-demand deployments, read cost is metered in read units; sustained high-throughput workloads can use Dedicated Read Nodes instead. Treat the pricing page and calculator as the current source of truth because plan allowances and regional rates can change.
07
Important limitations and cautions
Do not interpret GA as proof that BM25 is universally better than embeddings. Full-text search improves a different class of query. Also, Pinecone's product announcement is a vendor source; claims about operational simplicity or accuracy benefits should not be treated as independent benchmark results.
Some older Pinecone examples were written during public preview and may show preview namespaces or API versions. Developers implementing the feature should check the current GA documentation and SDK examples before copying preview code directly.
08
Who should care
The release is most relevant to teams building RAG, support agents, catalog search, recommendations, enterprise document search and workflow agents that need exact values. It is less important for applications whose queries are purely conceptual and whose corpus does not contain identifiers or literal constraints.
09
Bottom line
Pinecone Full-Text Search closes a practical gap in vector-first retrieval. Instead of maintaining one system for semantic similarity and another for exact keyword matching, developers can now keep lexical and vector search capabilities inside the same Pinecone database. For modern RAG and agent systems, the biggest benefit is not 'BM25 versus vectors' but the ability to use each retrieval method for the query type it actually handles well.
Sources
Primary and supporting sources
Facts were rechecked against the linked sources immediately before publication. Pricing, product availability and rollout status can change.