Pinecone: What It Is and How to Use It

Our stake is almost nil and worth declaring anyway: we are Geonode and we sell proxies, which have nothing to do with vector databases. The one adjacency is that a retrieval system needs something to retrieve over, and if that content comes from the public web, someone has to collect it — which is our end of the pipeline and entirely separate from the database. Nothing in this article requires buying anything from us, and the section arguing against a managed vector database is included because it is frequently the right answer.

What a Vector Database Does

Ordinary databases match exactly. A vector database matches by similarity.

The mechanism: an embedding model converts text, images or other content into a list of numbers — a vector — positioned so that similar things end up near each other. Finding relevant results becomes finding nearby points, which is a geometry problem rather than a string-matching one.

Pinecone describes itself as "the vector database for AI agents and applications, built for semantic search, knowledge retrieval, and long-term memory at scale", with the capability framed as searching "through billions of items for similar matches to any object, in milliseconds".

The reason this became infrastructure rather than a library is scale. Comparing a query against a million vectors by brute force is straightforward and slow; doing it in milliseconds requires approximate nearest-neighbour indexes, and running those reliably at scale is an operations problem. That is what a managed service sells.

The dominant use case is retrieval-augmented generation: given a user's question, find the most relevant passages from your own documents and give them to a language model as context. The database supplies the "find the relevant passages" step.

Indexes, Documents and Records

Pinecone's data model has changed shape and is worth understanding as it currently stands.

An index is where data lives. The documentation explains that "a serverless index holds your data as documents or records, depending on how the index was created: an index created with a document schema holds documents, while an index created with a dense or sparse vector type holds records".

A document schema lets one index do several jobs. According to the documentation, "a single index with a document schema can mix multiple ranking field types: a dense_vector field for semantic search, a sparse_vector field for sparse-vector retrieval, and one or more string fields with full_text_search enabled for full-text search with BM25 and Lucene queries."

Metadata needs no declaration. "Any other fields you upsert are stored as metadata, automatically indexed for filtering — no schema declaration required."

The design guidance is stated plainly: "One index per use case is the typical pattern. Because a document can combine vectors, text, and metadata in the same record, a single index often covers what previously required two — pick the ranking signal per query with score_by."

That last point is the significant one. Full-text search is available alongside vector search in the same index — "BM25 token matching with Lucene query syntax over text fields in your schema", with Pinecone handling "tokenization, IDF, and length normalization at index time and BM25 scoring at query time". No separate search engine, and no model required for the keyword half.

The practical consequence is that hybrid search — combining semantic similarity with exact keyword matching — is a query-time choice rather than an architecture. Which matters, because pure vector search is notoriously weak on exact identifiers, product codes and rare proper nouns, and BM25 is excellent at exactly those.

Namespaces

The feature that most affects how you design a multi-tenant application.

The documentation: "Within an index, records are partitioned into namespaces, and all upserts, queries, and other data read and write operations always target one namespace."

Two benefits are named. Multitenancy — "when you need to isolate data between customers, you can use one namespace per customer and target each customer's writes and queries to their dedicated namespace." And faster queries — "when you divide records into namespaces in a logical way, you speed up queries by ensuring only relevant records are scanned."

Three operational notes.

They are created implicitly. "Namespaces are created automatically during upsert. If a namespace doesn't exist, it is created implicitly." Convenient, and it means a typo in a namespace name produces a silently empty search rather than an error.

The limit is plan-dependent. "Namespaces per serverless index vary by plan. On the Standard and Enterprise plans, Pinecone can accommodate million-scale namespaces and beyond for specific use cases. If your application requires more than 100,000 namespaces, contact Support."

Isolation is the point. For anything holding several customers' data, one namespace per customer is the pattern, and it makes cross-tenant leakage a matter of getting one parameter right rather than getting a filter right.

Embeddings: Yours or Theirs

Two approaches, and the choice has real consequences.

Integrated embedding. The documentation describes it in four steps: "Create an index that is integrated with one of Pinecone's hosted embedding models. Upsert your source text. Pinecone uses the integrated model to convert the text to vectors automatically. Search with a query text. Again, Pinecone uses the integrated model to convert the text to a vector automatically."

Simpler — you send text and receive results, with no embedding pipeline of your own. One documented restriction: "Indexes with integrated embedding do not support updating or importing with text."

Bring your own vectors. You run the embedding model, create an index matching its characteristics, and upsert vectors directly, using "the same external embedding model to convert a query to a vector".

More work, and more control. It lets you use a model Pinecone does not host, run embedding locally for privacy or cost reasons, and — crucially — change models on your own schedule.

The consideration that decides it for many people: changing embedding models means re-embedding everything. Vectors from different models are not comparable, so a switch is a full re-index. Integrated embedding makes the initial build easy and ties the decision to the vendor's model catalogue; bringing your own makes the build harder and keeps the choice yours. Neither is wrong, and it is worth deciding deliberately rather than by whichever tutorial you followed first.

Loading Data at Scale

A cost note that is easy to miss and expensive to discover.

The documentation is specific: "To control costs when ingesting large datasets (10,000,000+ records), use import instead of upsert."

Two ingestion routes exist. Upsert sends records through the API. Import reads Parquet files from object storage, and the documentation calls it "the most efficient and cost-effective way to load large numbers of records into an index".

Given that writes are billed per million write units, the difference between these two paths on a large initial load is a real number rather than a rounding error. If you are building an index over millions of records, plan for the import path from the start — retrofitting it after an expensive first load is a lesson nobody needs to pay for twice.

Getting Started in Practice

The shape of a first implementation, and the decisions embedded in it.

Create an index and upsert. With integrated embedding the flow is short — you never touch a vector:

from pinecone import Pinecone

pc = Pinecone(api_key=API_KEY)

index = pc.Index(host=INDEX_HOST)

index.upsert_records(
    namespace="customer-42",
    records=[
        {"_id": "doc-1", "chunk_text": "Refunds are processed within 14 days.",
         "source": "policy.pdf", "page": 3},
        {"_id": "doc-2", "chunk_text": "Shipping to the EU takes 3-5 working days.",
         "source": "shipping.pdf", "page": 1},
    ],
)

Note that source and page were never declared. Anything beyond the ranking fields is stored as metadata and indexed for filtering automatically, which means you can add fields later without a migration.

Query with a filter:

results = index.search(
    namespace="customer-42",
    query={"inputs": {"text": "how long do refunds take?"}, "top_k": 5,
           "filter": {"source": {"$eq": "policy.pdf"}}},
)

Three decisions in that snippet are worth making deliberately.

Chunk size. The text you upsert is the unit that comes back, so chunking determines what your model sees. Chunks that are too small lose the context that makes them meaningful; too large and you retrieve mostly irrelevant text alongside the relevant sentence. There is no universal answer — a few hundred words with some overlap is a reasonable starting point, and measuring beats guessing.

Metadata is your filter surface. Store anything you might later want to narrow by: source document, date, section, language, access level. Adding it at upsert time costs nothing; adding it afterwards means re-upserting.

Namespace per tenant, always, from the beginning. Retrofitting isolation into a single-namespace index means re-upserting everything with the right target. Starting with namespaces costs one parameter and removes a whole category of future incident.

And keep the source text. Store the original documents somewhere you control, alongside the chunking code. If you change embedding model, chunk size or chunking strategy — and you will — rebuilding the index is a rerun rather than an archaeology exercise.

Pricing, Verified

From Pinecone's own pricing page, checked September 2026. Verify before budgeting.

Four observations that matter for planning.

The free tier is genuinely usable for evaluation. Two gigabytes of storage and a million monthly read units is enough to build a real prototype over a substantial document set.

Builder is a flat rate, not a minimum. At $20/month with fixed ceilings, it is predictable in a way the usage-based plans are not — useful for a small production application where you would rather have a bill you can forecast.

Standard and Enterprise are minimums with overage. The $50 and $500 figures are floors, not caps. Your actual cost is usage-based above them.

Reads cost roughly four times writes per million units. At $16–$18 per million read units against $4–$4.50 for writes, a read-heavy application — which most retrieval systems are — will find queries dominating the bill. Caching frequent queries is therefore a direct cost lever, not merely a latency one.

Enterprise adds a 99.95% uptime SLA, bring-your-own-cloud deployment, private endpoints and audit logs — the usual set of things that matter to a procurement process and nothing at all to a prototype.

When You Do Not Need a Managed Vector Database

The section a vendor would not write, included because it is frequently the answer.

When your corpus is small. Below roughly a hundred thousand vectors, brute-force similarity search in memory is fast enough on ordinary hardware. A NumPy array and a dot product will answer in milliseconds, cost nothing, and remove an external dependency from your architecture. The threshold where approximate indexing becomes necessary is higher than most people assume.

When you already run Postgres. The pgvector extension adds vector similarity search to a database you are already operating and backing up. For many applications this is the correct answer: one fewer system, transactional consistency with your other data, and no separate bill.

When an embedded library suffices. Libraries such as FAISS or a local vector store handle millions of vectors in a single process. If your data fits on one machine and your query volume is modest, a managed service is solving an operations problem you do not have.

When keyword search would work. A meaningful share of "we need semantic search" turns out to be well served by BM25, which is cheaper, faster, entirely explainable and better at exact identifiers. Try it first — and note that if you do end up on Pinecone, its full-text search covers this in the same index.

When you have not measured retrieval quality. The database is not usually the limiting factor in a retrieval system. Chunking strategy, embedding model choice and query formulation matter far more, and all three can be tested with a hundred lines of local code before any infrastructure decision is made.

The case for a managed service is real and specific: many millions of vectors, query volume requiring consistent low latency, multi-tenant isolation, and a team that would rather not operate a distributed index. If two or more of those apply, it earns its cost.

People Also Ask

What is Pinecone used for?

Semantic search, knowledge retrieval and long-term memory for AI applications. The dominant pattern is retrieval-augmented generation: finding the passages of your own documents most relevant to a question, and supplying them to a language model as context.

Is Pinecone free?

There is a free Starter plan with up to 2 GB of storage, 2M write units and 1M read units per month, and 1 GB of egress. It is genuinely enough to build and evaluate a real prototype before committing to a paid plan.

How much does Pinecone cost?

Starter is free; Builder is $20/month flat with fixed ceilings; Standard has a $50/month usage minimum and Enterprise $500/month, both billing storage at $0.33/GB/mo, writes at $4–$4.50 per million units and reads at $16–$18 per million, with egress at $0.10/GB after 100 GB.

What is a namespace in Pinecone?

A partition within an index. Every read and write targets exactly one namespace, which makes it the standard mechanism for multi-tenant isolation — one namespace per customer — and a performance optimisation, since queries scan only the relevant partition.

Should I use integrated embedding or my own vectors?

Integrated embedding is simpler: send text, Pinecone converts it. Bringing your own gives you model choice and portability, which matters because changing embedding models requires re-embedding everything. Integrated indexes also do not support updating or importing with text.

Can Pinecone do keyword search as well as vector search?

Yes. String fields with full_text_search enabled support BM25 ranking with Lucene query syntax, in the same index as dense and sparse vectors, with the scoring method chosen per query. This matters because pure vector search handles exact identifiers and rare terms poorly.

How do I load millions of records efficiently?

Use import from object storage rather than upsert. The documentation recommends this explicitly for datasets above ten million records and describes it as the most cost-effective route, which matters given that writes are billed per million units.

Do I need a vector database at all?

Often not. Below roughly a hundred thousand vectors, in-memory brute force is fast enough and free. If you already run Postgres, pgvector avoids a separate system. And a fair share of "semantic search" requirements are well served by keyword search, which is cheaper and more explainable.

Wrapping Up

Pinecone is a managed vector database that has grown into something broader: one index can now hold dense vectors, sparse vectors and full-text fields together, with the ranking method chosen per query. That consolidation is the most useful recent change, because hybrid retrieval stops being an architecture decision and becomes a parameter.

Three things shape how you should design against it. Namespaces are the isolation and performance mechanism, and they are created implicitly — so a mistyped namespace returns an empty result rather than an error. The embedding choice is stickier than it looks, since switching models means re-embedding your whole corpus. And reads cost several times what writes do, which makes query caching a direct cost lever in a read-heavy system.

The pricing is transparent and the free tier is large enough to answer the real question, which is whether retrieval quality is good enough for your use case. That question is not about the database — chunking, embedding choice and query formulation dominate it — and it can be answered locally before any infrastructure exists.

Which is the honest closing point. A managed vector database earns its place at scale, with multi-tenancy, or when you would rather not operate a distributed index. Below that, an array in memory or an extension on the Postgres you already run will do the job for nothing, and it is worth establishing which situation you are in before signing up for either.