Pinecone vs Weaviate vs Qdrant in 2026: which vector database should you actually run?

Short version: Pinecone is the one you pick when you want the vector database to be someone else's job, and you accept that there is no version of it you can run yourself. Weaviate and Qdrant are open source engines with managed clouds attached, so the managed bill is a convenience charge rather than the only door. Between those two, Weaviate wants to own more of your pipeline (schema, hybrid ranking, optionally the embeddings themselves) and Qdrant wants to be a fast, sharp store that you point at vectors you already made. Most teams should decide on the hosting question first and the feature question second, because the hosting question is the one that is expensive to change later.

That is the whole argument. The rest of this post is the evidence, plus current prices pulled from the three vendors' own pricing pages on 2 September 2026.

The specs, side by side

Architecture, and why the index matters less than you think

All three are HNSW graphs at heart, or in Pinecone's case something proprietary that behaves like one from the outside. Weaviate and Qdrant both document their index parameters and let you tune the graph, and both support scalar and product quantization to trade a little recall for a much smaller resident set. Qdrant's documentation on that tradeoff is the most explicit of the three, which is worth something when you are trying to size a node.

Pinecone does not expose the index at all. That is a design choice, not an oversight: their pitch is that index tuning is toil you should not be doing, and for a lot of teams that is correct. The cost is that when recall is worse than you expected, your debugging surface is the API and a support ticket, not a config file and a metrics endpoint.

The practical read is that the index type will rarely be the thing that decides your project. Vector search quality is dominated by your embedding model, your chunking strategy, and whether you filter before or after the search. The engine matters at the margins. Anyone who tells you a particular HNSW implementation is the reason their RAG system works is usually describing a retrieval pipeline problem they solved by accident.

Hosting is the decision that sticks

Pinecone is managed only. There is no binary, no container you can run in CI, no way to bring the same engine up on a laptop. If Pinecone raises prices, changes its metering, or stops fitting your compliance story, your options are to renegotiate or to rewrite your retrieval layer against a different engine and re-embed or re-import everything.

Weaviate and Qdrant give you a real exit. You can run either one locally, in CI, on a box you own, or on a managed service, and the client code is the same in every case. That is not a hypothetical benefit. The most common vector database migration we see is not one vendor to another, it is production-on-managed to also-running-in-CI, because someone finally got tired of integration tests hitting a shared cloud index and stepping on each other.

We would not start a serious project on Pinecone's Starter tier with a plan to migrate off later if things get expensive. Migrations off a closed engine are always more work than the plan says, because the thing you have to port is not the vectors, it is every assumption your code made about how filtering, pagination, and consistency behave. If the closed managed model is right for you, commit to it. If you think you might want out, start somewhere you can leave.

Pricing, and why these three numbers are not comparable

Every vendor here meters something different, which is why price comparison tables for vector databases are usually nonsense.

Pinecone charges for storage plus read units and write units. Storage is $0.33 per GB per month. On the Standard plan you also pay $4 to $4.50 per million write units and $16 to $18 per million read units, with a $50 per month usage minimum; Enterprise raises those to $6 to $6.75 and $24 to $27 with a $500 per month minimum. The Builder plan is the exception and is genuinely simple: $20 a month flat, capped at 10 GB, 5 million write units and 2 million read units. If your query volume is steady and modest, Builder is the easiest number in this entire post to reason about.

Weaviate Cloud charges on stored vector dimensions plus storage. Flex starts at $45 a month and prices dimensions from $0.00465 per million, dropping to $0.003875 on Premium and $0.002718 on Dedicated, with storage from $0.12 per GiB on Flex and $0.10 on Premium. Dedicated deployments start at $400 a month. The dimension metric is the one people get wrong: it scales with vector count multiplied by embedding width, so moving from a 768-dimension model to a 3,072-dimension one quadruples that line item without a single extra document.

Qdrant Cloud publishes a genuinely free forever tier at 0.5 vCPU, 1 GB RAM and roughly 4 GB of disk, and then meters paid clusters on vCPU, memory and storage. It does not publish per-unit rates on the pricing page; you are sent to a calculator. Third-party comparisons quote an hourly figure for the smallest paid node, but we could not confirm it on a page Qdrant owns, so we are not repeating it. Premium requires a minimum spend and the hybrid and private cloud options are quote-only.

The honest summary is that usage-metered vector pricing is unpredictable exactly when it hurts, which is when a feature gets popular. Read units in particular scale with traffic you do not control. If your finance team wants a number they can put in a spreadsheet, a flat plan or a self-hosted node will serve you better than any per-million rate.

Filtering and hybrid search

Filtering is where vector search meets reality. You almost never want the nearest neighbours in the whole corpus; you want the nearest neighbours belonging to this tenant, published after this date, in this language.

Weaviate and Qdrant both support pre-filtering, meaning the filter constrains the search rather than pruning its results afterwards. That matters on large collections, because post-filtering can return you an empty page when your filter is selective. Pinecone's metadata filtering does the job, but you get less visibility into how the filter interacts with the index, so when a filtered query behaves unexpectedly you have fewer levers.

On hybrid search the three genuinely differ. Weaviate's BM25 and BM25F integration is the most complete: one query, a tunable blend between keyword and vector scores, and documentation aimed squarely at product search. Qdrant supports dense and sparse vectors together and several sparse encoders, which gives you more control and more assembly work, since you own the fusion. Pinecone supports sparse vectors alongside dense ones and added BM25-ranked text fields, so hybrid is available without leaving the managed API.

If hybrid ranking is the core of your product rather than a nice-to-have, Weaviate's version is the one that requires the least glue. If you want to control how dense and sparse scores combine, Qdrant will let you, and the head-to-head detail lives in our Qdrant vs Weaviate comparison. If you are still deciding whether you want vector search at all rather than a good keyword index, full-text search vs vector search is the more useful read first.

Multi-tenancy and scale

Pinecone's namespaces are the simplest model: one index, logical partitions inside it, no per-tenant provisioning. It scales without you thinking about it, which is the entire product.

Weaviate has explicit multi-tenant collections designed for exactly this shape, including the ability to offload inactive tenants so you are not paying to keep every customer's vectors hot. For a B2B SaaS with a long tail of small tenants, that is the most purpose-built option of the three.

Qdrant handles tenancy through collections and payload-based partitioning, with sharding and replication for horizontal scale. It is more manual and more transparent, which suits teams who want to know exactly where data lives, and suits data residency requirements that a shared managed index cannot satisfy.

Clients and the framework question

This is close to a tie and should not decide anything. All three ship official clients for Python, JavaScript and Go, with Qdrant adding Rust and Weaviate adding Java. All three have first-party integrations in LangChain and LlamaIndex, and swapping a vector store between them in either framework is a small change on the retriever config.

Do not pick an engine because a framework tutorial used it. The framework abstraction is thin, and the things it abstracts away, filtering semantics and hybrid ranking, are the things you will care about in month three.

Running Weaviate or Qdrant on Layerbase Cloud

Pinecone cannot be on this list, because there is nothing to host. Weaviate and Qdrant can, and both run on Layerbase Cloud today: Weaviate 1.38 and Qdrant 1.18, as managed HTTPS endpoints with the official clients connecting unchanged against a dashboard-issued API key.

Both are Performance engines here, which means they require the $15 a month Pro plan and are always on rather than sleeping when idle. Vector indexes are resident data structures, and a vector database that hibernates and reloads its graph is not a vector database anyone wants. Pro includes a shared always-on pool of 1.5 GB of RAM and 25 GB of storage across up to 10 databases; creating a Qdrant draws 512 MB from that pool and a Weaviate draws 768 MB, and if you need more you add pool blocks at $10 a month each. The price is flat. There is no read unit, no write unit, and no per-dimension meter, so the bill does not move when a feature gets popular. Pro comes with a 7-day trial if you want to size it against your own corpus first.

Two things follow from being ordinary managed databases rather than a bespoke vector service. Both engines branch, so you can fork a populated index into a throwaway copy for a schema change or a re-embedding experiment without rebuilding it, which is covered in branching vector databases. Both are reachable over the HTTP query API, so an edge runtime that cannot open a raw socket can still query them. And because Layerbase Cloud runs 18 engines on one account, the Postgres holding your documents and the Qdrant holding their embeddings live in the same dashboard and the same bill, which is most of the point if you are building the kind of stack described in the best database for AI agents.

If you want to try either engine on your own machine first, both are free to run locally with the Layerbase CLI, and the walkthroughs are in getting started with Qdrant and getting started with Weaviate.

Which one to pick

Pick Pinecone if nobody on your team wants to think about vector infrastructure and you are comfortable with that being permanent. The Builder plan at $20 a month flat is a good deal for a small, steady workload, and the managed API is mature and well documented. Go in knowing that the exit is a rewrite.

Pick Weaviate if hybrid keyword and semantic search is the product rather than a component, or if you have a lot of small tenants and want the tenancy model built for that. It asks you to accept a schema and more opinions, and gives you the most complete hybrid ranking of the three in exchange.

Pick Qdrant if you already own your embedding pipeline and want a fast store that stays out of the way, if you need to control where the data physically lives, or if cost predictability matters more than a polished managed console.

The one recommendation we will make without hedging: if you are prototyping and do not yet know which of these you need, start on one of the open source engines. Both run free on your laptop and both have real free managed tiers, so the cost of being wrong is a few hours rather than a migration. You can decide later whether to pay someone to run it, and that decision stays cheap precisely because you did not make it first.

Create a managed Qdrant or Weaviate on Layerbase Cloud and connect with the client library you were already using.