Pinecone adds integrated embedding to its Documents API, so users send only text
Pinecone has added integrated embedding to its Documents API, so developers can send raw text and let the service run the embedding pipeline on every write and every search. According to the company, one text field can now serve both semantic and full-text search, and embedding and search are billed together on one Pinecone invoice.
- Pinecone's Documents API now embeds text on every write and search, so users send only raw text.
- One text field serves both semantic and full-text search, and the application chooses the method per request.
- Three models at launch: llama-text-embed-v2, multilingual-e5-large and pinecone-sparse-english-v0.
- Embedding and search are billed together on one Pinecone invoice, according to the company.
- The Records API from 2024 was limited by its design on top of the Vectors API, which the new Documents API addresses.
What changes for developers
For most of Pinecone's history, users had to turn both their data and each search query into vectors themselves, using their own embedding pipeline. Pinecone first moved embedding inside the database with the Records API in 2024. The company now offers the same approach in the Documents API, which also supports full-text search.
According to Pinecone, teams no longer have to vet an embedding provider or build and maintain a pipeline that calls one. Before, a platform team had to support that pipeline on both the write path and the query path, with its own keys, rate limits, retries and monitoring. Integrated embedding runs the models inside Pinecone instead.
Pinecone says documents and queries are embedded with the same model, so a query is never compared against vectors made by a different one. When a document changes, Pinecone embeds the new text in the same write. Semantic and full-text search both reflect the change, with no re-embedding job to schedule or monitor.
Models and setup
Three embedding models are available at launch:
- llama-text-embed-v2 is the default for semantic search and handles long passages in 26 languages.
- multilingual-e5-large is an alternative for multilingual text.
- pinecone-sparse-english-v0 adds keyword-style matching that learns which words matter most in each passage.
Developers add an embedding model to a text field in the index schema, next to that field's full-text search setting. Pinecone then uses it for every document and every query on the field. Users can also choose any dimension the model supports. To add sparse retrieval on the same field, they add a sparse_embed setting with pinecone-sparse-english-v0. The index description shows the model, dimension and metric each field uses.
The application picks the search method for each request, lexical or semantic, through the same API and the same field.
How Pinecone got here
In an engineering post, Silas Smith describes the path to this release. In the original Vectors API, users had to wire in a third-party embedding provider and often build the integration twice, once for writes and once for queries. They also had to decide where to keep the source text, either in a separate data store or in a metadata field, which adds storage and write costs.
Pinecone laid groundwork in 2024 and 2025. It began hosting models itself in 2024, adding standalone embed and rerank endpoints. In early 2025 it shipped the slab architecture for serverless indexes, which Smith says made index selection composable for kinds of indexes beyond vectors. Full-text search later became one of them.
The Records API, launched in late 2024, proved the pattern of bringing text and letting embedding happen inside Pinecone. Smith writes that it was ultimately premature. It wraps the Vectors API, the text still lives in a metadata field, and each index was tied to one model and one text field. It also had no room to support native full-text search.
In late November 2025 the engineering team met in NYC and settled on three pieces: native full-text search in the slab architecture, a flexible schema language, and a document API and search API to build on. Document indexes support a user-defined schema of typed fields. At first release these were string fields for full-text search, dense and sparse vector fields, and metadata for filtering. According to Smith, a full-text field keeps the raw text once in the slab and builds a Tantivy inverted index next to it, scoring results with BM25.
What it means for teams
The change is aimed mainly at teams that want semantic search without running a separate embedding stack. Platform teams get one vendor to support rather than a new provider and pipeline for each application, and one invoice covers embedding and search. Application teams can switch between keyword and semantic retrieval on a single field. Pinecone's stated goal, in Smith's words, is for users to spend more time building their application and less time building retrieval pipelines.
