Pinecone brings Google’s Gemini Embedding 2 into its managed search workflow
The integration handles model calls and billing, but requires new serverless Documents API indexes and does not guarantee a processing region.
Loading page…
The integration handles model calls and billing, but requires new serverless Documents API indexes and does not guarantee a processing region.
Listen to this story
Announced November 12, 2026, Pinecone has added Google’s Gemini Embedding 2 to its integrated embedding service, making model calls, retries and token billing part of Pinecone’s Documents API rather than a separately managed Google connection. The integration is limited to new serverless Documents API indexes on Builder or higher; it currently accepts text, and Google may process requests in any region. It simplifies managed semantic search, but teams with existing indexes, multimodal needs or regional processing requirements cannot yet use it as-is.
Builder normally includes 10 million Gemini Embedding 2 tokens monthly; Pinecone temporarily raises that to 20 million through December 31, 2026, billed at Google’s list price.
Developers can set embedding dimensions, including 1,536, and select task types such as classification or question answering.
Pod-based, bring-your-own-cloud and Records API indexes are excluded; converting an existing vector index does not yet enable integrated embedding.
Pinecone customers can now send plain text for Google’s Gemini Embedding 2 to turn into searchable data, without running a separate Google account or managing its API key. Announced November 12, 2026, the integration puts document and query embedding inside Pinecone’s Documents API, shifting model calls and billing into the database service.
This is a new route to an existing model, not a new Google model release. Google made Gemini Embedding 2 generally available on April 22. Pinecone’s announcement adds it to integrated embedding alongside the Pinecone-hosted models the feature already supported.
Embeddings are the model-generated representations used for semantic search: finding text by meaning rather than only matching words. Developers select Gemini Embedding 2 for a text field when creating an index. Pinecone then embeds every document write and every search query for that field.
A search request can contain the query as ordinary text. Pinecone makes the embedding call and runs the search in one request. It serves the model through Google Vertex AI and retries failed calls, removing the need for teams to build that retry logic themselves.
The integration also writes each document’s text and embedding together. Pinecone says this keeps keyword and semantic search working from the same document version. It automatically adds the instructions Gemini Embedding 2 expects to distinguish documents from queries, so developers do not have to supply model-specific prompts.
Embedding tokens appear on the Pinecone invoice at Google’s list price, rather than on a separate Google bill. Access requires Pinecone’s Builder plan or higher. The company is temporarily doubling Builder’s included monthly allowance for this model; that promotion ends December 31, 2026.
Pinecone’s Python example configures a text field for both full-text search and Gemini embeddings at 1,536 dimensions. Developers can choose any dimension size the model supports. Leaving the dimension setting out uses the model’s full size.
General search is the default, but the task_type setting lets developers specify other uses. A field can be configured for classification, clustering or sentence similarity. Individual queries can instead specify question answering, fact verification or code retrieval. These settings describe the intended task, rather than requiring developers to write their own instruction prefix.
The initial availability has several boundaries that matter before a team changes its search setup:
Pinecone says the model supports text in more than 100 languages. Processing is global: Google can handle each request in any of its regions, with no specific region guaranteed. That is a material constraint for teams that need requests processed in a particular location, even if the managed workflow removes account and API work.
Loading discussion...
Join the conversation
Explain when processing location matters more than simpler setup.
Be the first to share a perspective or an experience.
Reader comments
Newest comments first. Replies stay oldest first.