Pinecone

The managed answer

Every other store in this section asks you to run something. Chroma starts embedded, LanceDB is a library, Supabase Vector lives in Postgres you already operate, and Weaviate is a service you deploy.

Pinecone is the one where the answer to "who runs it" is nobody on your team. You create an index and write to it.

One naming note before anything else: new indexes are document-based by default, with vector indexes still supported, and both handle semantic and keyword search. Older tutorials describe a vector-first model, and pods, which do not appear in the current serverless documentation.

Namespaces are the multi-tenancy answer

This is the feature worth building around. Namespaces partition data inside an index, giving you multitenancy and faster queries, and they are created automatically during upsert. Plan limits run from 100 to 1,000,000.

The automatic creation is what makes them usable. Writing a record with a new namespace creates it, so tenant onboarding needs no provisioning step.

More importantly, a namespace is a hard partition rather than a filter you remembered to apply. Context security describes the tenant-leak shape where a filter runs after retrieval and looks correct in testing because every result belongs to the asker anyway. A per-tenant namespace removes that class of bug by construction: the query cannot reach another tenant's vectors because it is not searching them.

If you are multi-tenant, use one namespace per tenant and do not rely on metadata to keep customers apart.

Metadata, with two limits to design around

Metadata is key-value pairs attached to records, indexed for query-time filtering so a query can narrow the search.

Two constraints:

Flat JSON, no nesting. A nested object has to be flattened into keys, so decide the shape early. Rewriting it later means re-upserting the corpus.

40 KB per record. Generous for attributes, and not a document store. Keep the text in your own database and put an ID in the metadata rather than the body.

Integrated embedding removes a pipeline

Two ways to get vectors in. Integrated embedding has Pinecone convert text to vectors with hosted models. Bring your own means you embed elsewhere and upsert vectors directly.

Integrated is less to run: no embedding service, no queue, no version skew between the model that indexed a document and the model that embeds the query. That last one is a real class of bug, and embedding models is right that the pairing has to stay consistent.

What you give up is the choice. Cohere Embed's multilingual coverage or a model you fine-tuned is not available through the integrated path, and moving from integrated to your own later means re-embedding.

Start integrated for a prototype. Decide deliberately before the corpus is large.

Search beyond dense vectors

Full-text BM25, dense semantic search, sparse-vector search, and hybrid combinations are all supported.

That matters for the queries pure vector search loses, which Weaviate covers in depth: exact product codes, names, and rare terms where lexical matching beats semantic similarity. Having both in one index means you are not running a second system to catch them.

When it earns its cost

Reach for Pinecone when you do not want to operate a search system, when multitenancy is a requirement and namespaces solve it cleanly, or when you want managed embedding as well as managed storage.

Look elsewhere when the data cannot leave your infrastructure, when your corpus is small enough that purpose and functionality is right that you do not need a vector database at all, or when you want control over the index parameters that indexing embeddings describes. A managed service chooses most of those for you, which is the point and the limitation.

Further reading

• Pinecone, Indexing overview: document and vector indexes, namespaces, metadata limits and embedding options.
• Weaviate: hybrid search, and tuning it.
• Context security: why a namespace beats a filter for tenant isolation.
• Purpose and functionality: whether you need one of these at all.