What do you like best about Pinecone?
Serverless is the architecture decision that made me commit. I create an index, pick the cloud and region, and start upserting vectors within a couple of minutes, with no cluster to size, no shards to plan, and no capacity math before I know what the workload even looks like. The part that matters day to day is that an idle index costs nothing. Two of our client projects are seasonal, with traffic that goes quiet for weeks at a time, and under the old world of provisioned pods we would have been paying for compute that sat there doing nothing. With serverless the bill follows the usage, and when a campaign spikes the index absorbs it without me touching anything. That is the whole promise of managed infrastructure, and here it is actually kept.
Query latency has been consistently where I need it. Our main RAG application runs similarity search over a few million 1536-dimension vectors, and responses come back in the low tens of milliseconds at p95, steady enough that we stopped graphing it obsessively after the first month. Upserts land in near real time, so when a client updates a document the corrected content is retrievable within seconds rather than after a nightly rebuild. For a support-facing assistant that difference is visible to end users.
Namespaces are the feature I underestimated at first and now design around. Each of our client workspaces lives in its own namespace inside a single index, which gives me tenant isolation without spinning up an index per customer or bolting a filter onto every query by hand. Creating a namespace is free and instant, deleting one wipes a tenant cleanly, and the whole multi-tenant layer that I expected to build in application code simply is not there anymore.
Metadata filtering deserves its own mention. Being able to attach structured metadata to each vector and then filter at query time, in the same call as the similarity search, collapses what used to be a two-step dance into one. When I need documents similar to a query but only from a specific product line and only published after a certain date, that is one request. The filter runs as part of the search rather than as a post-filter over results, so I am not over-fetching candidates and trimming them myself.
The integrated inference is a more recent habit. Pinecone hosts embedding models directly, so I can upsert raw text and let the platform handle the embedding step as part of the write, and the same on the query side. For smaller projects this removed an entire service from our architecture: no separate embedding endpoint, no version drift between what indexed the documents and what embeds the queries. On our larger project we still run our own embedding model for control reasons, and the platform is equally comfortable with vectors I bring myself.
A handful of smaller things that just work and rarely get mentioned:
- The Python SDK is clean, typed, and matches the docs, which is not a given in this category
- Bulk import from object storage, so backfilling an index from a Parquet dump in S3 is a managed operation rather than a script I babysit
- Backups of serverless indexes, which turned our disaster recovery story from a plan into a button
- The status page reports per-endpoint health honestly, including during incidents
The free Starter tier is a real tier, not a demo. It holds enough vectors to prototype a genuine application, roughly the scale of a small production knowledge base, and it carries no time limit and no monthly minimum. Every new retrieval idea we test starts there. By the time a project graduates to a paid plan, the index design has already been validated against real data, which means the first paid invoice funds a workload we understand rather than an experiment.
Hybrid search with sparse vectors earned a place in one of our projects where pure semantic retrieval kept missing exact terms. Product codes, legal references, and proper names are the classic failure cases for dense embeddings, and combining a sparse representation with the dense one in the same index recovered those matches without a separate keyword engine sitting beside the database. Tuning the balance between the two took some experimentation, more than the docs prepared me for, but the capability being native to the platform meant the experimentation happened in queries rather than in architecture.
The console is unglamorous and useful. I can inspect index stats, watch read and write unit consumption, and sanity-check a query without writing code. It does what an operations view should do and nothing more, and I mean that positively.
Support has been responsive on the two occasions I needed it, once for a billing question and once for guidance on index design for a high-cardinality metadata field. Both times I got an answer from someone who clearly understood the product internals rather than a script. Review collected by and hosted on G2.com.
What do you dislike about Pinecone?
Cost predictability at scale is the honest criticism, and it is the one thing I actively manage rather than trust. The read unit and write unit model is transparent on paper, but the mapping from application behavior to units consumed takes real effort to internalize. A query with a heavy metadata filter can burn several read units instead of one, and a chatty ingestion pipeline that rewrites vectors frequently will run up write units in ways a naive estimate misses. Our first month on Standard came in noticeably above my back-of-envelope calculation, almost entirely from filtered queries. The fix on our side was concrete: we cached repeated queries at the application layer, moved to smaller embedding dimensions where retrieval quality allowed it, and set billing alerts. Since then the invoice has been boring, but reaching boring took deliberate work, and a team that skips that work will get a surprise.
Pinecone is purely a vector database, and you feel that boundary quickly. Anything relational, transactional, or simply structured still lives in Postgres next to it, and keeping the two in sync is our code, our problem. Metadata on vectors covers filtering but it is not a substitute for a real query layer over structured data. I do not think this is the wrong scope for the product, but anyone evaluating it should budget for the second database and the synchronization logic, because you will write both.
Documentation is strong on the main paths and thinner at the edges. The getting-started material and API reference are genuinely good. Where I have had to experiment my way through is the advanced territory: tuning hybrid search with sparse vectors, understanding exactly how filter selectivity interacts with read unit consumption, and best practices for very high namespace counts. The docs assistant they provide is hit or miss on precisely these edge questions. My workaround has been the community forum plus trial and error in a staging index, which works but should not be necessary for a product this mature.
The platform has also evolved fast, and the churn has a cost. Over the time I have used it, the Python client went through a significant interface change and the way indexes are referenced shifted with the serverless transition. Every change was an improvement in isolation, and migration guides existed, but I have twice spent an afternoon updating code that worked fine the week before. The pace has settled recently. I would still pin SDK versions in production and read the changelog before upgrading, which is the habit those afternoons taught me.
There have been a couple of brief availability blips, generally traceable to the underlying cloud provider rather than Pinecone itself, and always visible on the status page in real time. None lasted long enough to page us seriously, but if your tolerance for third-party outages is zero, that is a property of any managed service and this one is no exception. Review collected by and hosted on G2.com.
