Recover and load the source records
Identify where every Pinecone namespace originally came from and load those records into tables or buckets. If a source was never retained, recover it now — this is the only step that cannot be done later.
Declare the vector index
Add a vector search index over the source tables and buckets in stack.json, with text-embed-v1 or a custom inference endpoint as the embedding source. Review the plan like any other schema change.
Run the parity query set
Take fifty real queries from production traffic and compare result quality between Pinecone and the new index, including metadata-filtered searches. Fix chunking and field choices while both systems are live.
Shift reads, then delete
Point application reads at the project index, observe quality in production, and stop the sync pipeline. Delete the Pinecone index and close the account only after a full traffic cycle on the new index.
Your vectors are not the asset. Your source records are.
Everything in a Pinecone index arrived there from somewhere: product records, documents, support articles, chunks of a corpus. That origin decides the migration shape. If the source lives in a database or object store you control, the move is a re-index: load or keep the source in KERNSTACK tables and buckets, declare a vector index over it, embed with text-embed-v1 or your own declared endpoint, and let the platform build the index from truth instead of from a pipeline’s memory of truth.
The awkward case is an index whose source was never kept — vectors upserted from a pipeline that discarded the originals. Then the originals must be recovered from whatever system produced them before Pinecone is switched off. This is discoverable in an afternoon and unfixable after deletion, which is why the guide puts it in the first section rather than the FAQ.
- Namespaces become separate indexes or separate source tables — decide per namespace whether it was a tenant boundary or a content type.
- Metadata filters map to fields on the source records; filtering behaviour should be in the parity query set, not assumed.
- Sparse and hybrid configurations deserve an explicit check: declare the text index beside the vector index and test the queries users actually run.
Parity first, deletion last
The safe sequence runs both systems against the same questions. Build a query set from real traffic — the fifty searches your users actually make, with the results support would call correct — and score the new index against it before any application traffic moves. Discrepancies are almost always chunking or metadata decisions, and they are cheap to fix while Pinecone is still the production answer.
When parity holds, shift reads, watch result quality the way you would watch latency, and only then delete the Pinecone index. The sync pipeline — embedding jobs, upsert hooks, delete propagation — is decommissioned in the same motion; removing it is most of the operational saving, and it only happens once nothing writes to the old index.
Resource-by-Resource Mapping from Pinecone
- Pinecone index →
vector-search index: Declared over the tables and buckets holding your source records, inside the same stack.json as the functions that query it. - Namespaces →
separate indexes or source tables: Map each namespace to its own index or its own source table, depending on whether it separated tenants or content types. - Upsert and sync pipeline →
deleted, not replaced: The index derives from the source of truth in the project. The embedding jobs and delete-propagation glue are decommissioned, which is the operational point of the move. - Embedding model calls →
inference catalogue: text-embed-v1 at 3 credits per 1,000 tokens, or a custom inference endpoint you declare for a model you already run. - Metadata filtering →
fields on source records: Filters apply to fields of the table records the index is built over. Include filtered queries in the parity set; do not assume equivalence. - Pinecone API keys in your services →
project-internal access: Queries come from your functions and workers inside the project. A vendor key leaves your secrets store, and a vendor leaves your incident channel. - Serverless versus pod-based indexes →
one declared index: The distinction was capacity plumbing at a second vendor. In the project it collapses into the index declaration and the credit meter behind it.
Frequently asked questions
Almost never. Vectors are derived data; re-embedding from source records with today’s model produces a cleaner index than importing vectors embedded by last year’s model. The cost is predictable — 3 credits per 1,000 tokens with text-embed-v1 — and the parity query set verifies quality before cutover.
When retrieval is itself the product at serious scale: extreme vector counts, specialised index types, or latency budgets a project-integrated index is not designed for. A dedicated vector database earns its place there. Product search over a catalogue or corpus is usually paying the sync tax for capacity it never uses.
Result quality, quietly. Chunking differences and dropped metadata fields do not throw errors; they return slightly worse answers that users experience as the product getting dumber. The parity query set exists because this failure mode is invisible to every health check you have.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.