Pinecone

Pinecone made vector search a service at the moment retrieval-augmented generation became the default architecture for grounding language models, and that timing built the category’s best-known brand.

The argument for a managed vector database

Vector search at scale is not conceptually hard and is operationally tedious. Sharding, replication, index rebuilds after a large ingest, memory pressure as the corpus grows, latency tuning, and the recall-versus-speed trade-off that has to be re-derived every time the data changes shape.

None of that differentiates your product. Paying someone else to operate it is a reasonable trade for most teams, and Pinecone’s serverless model — where you stop provisioning pods and start paying for what you read and write — removed the sharpest edge of the old pricing, which punished teams for over-provisioning capacity they could not accurately predict.

Metadata filtering combined with vector search is the feature that matters most in practice and is easy to overlook when evaluating. Real applications almost never search the whole corpus; they search this customer’s documents, from this date range, of this type. Getting filtered vector search right is harder than it looks and Pinecone does it well.

Namespaces make multi-tenant isolation straightforward, which is the shape of most B2B applications and a genuine source of bugs when hand-rolled.

The argument against has strengthened considerably

Postgres with pgvector handles small and medium corpora competently, inside a database you already run, back up and monitor. Embedded libraries handle single-node workloads with no infrastructure at all. Open-source vector databases cover the middle ground, and several managed competitors now price aggressively.

The honest evaluation question is scale. Below a few million vectors with moderate query rates, a dedicated managed vector database is frequently a solution to a problem you do not yet have — and it adds a service, a bill, a failure mode and a data-synchronisation problem that keeping vectors next to your relational data avoids entirely.

The teams who benefit most are those with genuinely large corpora, high query concurrency, or a hard requirement that retrieval latency stay flat as the index grows.

Other things worth knowing

Costs are usage-based and therefore variable, and applications with bursty read patterns can produce bills that are hard to forecast from a design document. Model it against realistic traffic before committing.

There is no self-hosted option. For data-residency requirements that rule out a third-party service, Pinecone is simply not a candidate regardless of its merits.

And vector search is only one part of retrieval quality. Chunking strategy, embedding model choice, hybrid keyword-plus-vector scoring and reranking typically move output quality more than which vector store you picked. Teams that treat the database as the hard part usually have a retrieval pipeline that underperforms for reasons the database cannot fix.

Pricing

A free starter tier sufficient for prototyping, usage-based serverless billing for production, and enterprise plans with support and additional controls.

The free tier is genuinely useful for evaluation, which makes the sensible approach obvious: build the retrieval pipeline, measure quality, and only then decide whether the storage layer needs to be a dedicated service.

Who should choose it

Teams with large-scale retrieval requirements, applications where query latency is a product constraint, and organisations that would rather buy than operate.

Teams already running Postgres with a corpus under a few million vectors should start with pgvector and migrate if they outgrow it — the migration is not hard and the premature adoption is a real cost. Teams with data-residency constraints need a self-hostable option.

Our explainers on the underlying architecture are at vector databases explained and what is RAG.