Pinecone setup for search and RAG

Decisions we make before creating an index

Some Pinecone settings are painful to change later. The index dimension must match the embedding model, so changing the model means building a new index and re-embedding every record. We therefore settle these points first.

Sizing math you can do yourself

Storage is easy to estimate. Each dimension of a standard vector is stored as a 32-bit number, which is 4 bytes. Take 50,000 chunks from your documents and an embedding model with 1,536 dimensions.

So a mid-sized document set is small in absolute terms, and the bill is usually driven by read and write volume and by how many separate indexes you run, not by raw storage. We list your expected reads and writes in the quote assumptions and tell you which plan terms to check. Our AI chatbot cost calculator helps you model the rest.

What a setup usually contains

We have no published case study on Pinecone, so this is the typical scope and not a client story.

1. Embedding testCompare two or three embedding models on 50 to 100 real questions and choose using retrieval hit rate.
2. Index and namespace designCreate the index, define namespaces per tenant or per document set, define the metadata fields.
3. Ingestion jobBatch upserts with stable record IDs, so re-running a file replaces its chunks rather than duplicating them.
4. Query layerFilters for access group and date, optional hybrid search, optional reranking of the top results.
5. OperationsDeletion path for removed files, a re-index procedure, monitoring and a backup of the source text.

The application on top is usually a RAG chatbot. If your documents are complex PDFs, see also our LlamaIndex page.

Gotchas

• Freshness. After an upsert, a record may take a short time to appear in queries. Do not build a flow that writes a record and instantly expects to read it back.
• Metadata limits. Each record can hold only a limited amount of metadata, so store the full text elsewhere and keep an ID in the record.
• Stable IDs. Random IDs make updates and deletes impossible to target. Derive IDs from file and chunk position.
• Access control. Filtering by user group must happen in the query itself. Hiding results after retrieval can leak content through the answer.
• Deleting data. Personal data removal requests need a way to find and delete every chunk of a person's file. Metadata makes that possible.
• Stale vectors after a model upgrade. Mixing old and new embeddings in one index produces poor results.

Do you need Pinecone at all

Not always. If you already run PostgreSQL and have under a few hundred thousand chunks, the pgvector extension may be enough and removes a vendor. If you need very high query volume, multiple regions or low operations effort, a managed service earns its place. We recommend the smaller option when it fits, and the decision is part of the first week.

Timeline