Vector databases: what each actually costs
Pinecone, Weaviate, Qdrant and pgvector at three scales, including the operational cost.
By Ahsan Ahmad, Chief Executive Officer · Last reviewed
Below about a million vectors, use pgvector in the Postgres you already run. One fewer system to operate is worth more than a latency difference nobody will notice, and the migration path later is straightforward.
Above that, the choice is between self-hosted Qdrant - cheapest in fees, real in operational burden - and a managed service, where you pay more and think about it less. The store matters far less to retrieval quality than chunking, the embedding model and whether you re-rank. Choose on operational fit, not on benchmarks.
Vendor pricing last checked 22 September 2026. All of these providers change their plans - verify before budgeting.
Which vector database should you use?
Start with pgvector if you already run Postgres and have under about a million vectors. Self-hosted Qdrant is cheapest in fees at scale but you operate it; Pinecone is managed only and needs no operational thought; Weaviate offers built-in hybrid search. Choose on operational fit, not on benchmarks.
| Option | Model | Strongest at | Weakest at |
|---|---|---|---|
| pgvector | An extension in your existing Postgres | Small and medium corpora, relational filtering, one less system | Very large corpora, and index rebuilds competing with transactional load |
| Qdrant (self-hosted) | A container you run | Per-tenant namespaces, payload filtering, cost at scale | You operate it - upgrades, backups, capacity |
| Qdrant Cloud | Managed | The above without the operations | Another vendor relationship and bill |
| Pinecone | Managed only | Scale with no operational thought at all | Cost at volume, and no self-hosted escape hatch |
| Weaviate | Self-hosted or managed | Built-in hybrid search and a module ecosystem | More concepts to learn than most projects need |
What does a vector database cost at 100k, 1M and 10M vectors?
By our estimate, roughly nothing extra on Postgres you already run up to a million vectors, tens of dollars a month for any option at 100,000 vectors, around $70 to $160 on managed services at a million, and several hundred to over a thousand dollars at ten million. At every scale, your own operating time can outweigh the fee difference.
Assuming 1,536-dimension embeddings and a moderate query rate. Treat these as orders of magnitude rather than quotes - every provider prices on a different combination of storage, compute and queries. Check the current plans on the Pinecone, Qdrant and Weaviate pricing pages before budgeting.
| Option | 100k vectors | 1M vectors | 10M vectors |
|---|---|---|---|
| pgvector on existing Postgres | $0 marginal | $0-30 marginal | Not recommended |
| Qdrant self-hosted | $12-25 VPS | $30-60 VPS | $120-300 VPS |
| Qdrant Cloud | ~$25-40 | ~$70-140 | ~$400-800 |
| Pinecone serverless | ~$10-30 | ~$70-150 | ~$500-1,200 |
| Weaviate Cloud | ~$25-50 | ~$80-160 | ~$450-900 |
| Your operating time, self-hosted | ~1 hr/month | ~2 hrs/month | ~4-8 hrs/month |
The last row is the one that decides it. At 1M vectors the fee difference between self-hosting and managed is roughly $80 a month - about one engineering hour. If running it costs you two, managed is cheaper and you have been arguing about the wrong number.
When is pgvector enough?
More often than vendor marketing suggests. pgvector is enough when you have under about a million vectors on hardware you already pay for, your filters are relational and live in the same database, you need a document and its embedding to stay consistent, and your team already runs Postgres well. This is the section worth taking away.
- Under a million vectors, on hardware you already pay for.
- Your filters are relational - owner, date, status, tenant - and live in the same database. Joining beats synchronising two systems.
- You need transactional consistency between a document and its embedding. In one database that is free; across two it is a distributed systems problem.
- Your team already operates Postgres well. Competence with a system is worth more than a benchmark.
Reach for a dedicated store when you pass a few million vectors, need per-tenant namespace isolation with strict guarantees, or find index rebuilds interfering with your production workload. We used Qdrant for exactly those reasons on the Klebbix build - multi-tenant isolation was a hard requirement and namespaces made it testable.
What actually improves retrieval quality?
Chunking strategy first, then re-ranking, then hybrid retrieval that combines vector search with keyword and structured filters, then an embedding model benchmarked on your own corpus, and finally query rewriting. The vector store is not on this list, which is the point: switching databases rarely fixes a relevance problem.
- Chunking strategy: size, overlap, and whether chunks respect document structure. Tune it against a labelled set rather than accepting a default.
- Re-ranking: retrieve broadly, re-rank narrowly. The cheapest large quality gain available, and it costs a few milliseconds.
- Hybrid retrieval: vector search plus keyword and structured filters. Embeddings are reliably bad at exact identifiers and dates.
- The embedding model, benchmarked on your corpus rather than on a leaderboard.
- Query rewriting, when your users ask questions in a very different register from the documents.
How we put those together is on the RAG systems page.
How do you avoid getting locked into a vector database?
Start on pgvector. Keep the retrieval layer behind an interface with two methods - upsert and search - so nothing above it knows which store is underneath. If you outgrow it, moving is a re-index and an adapter, measured in days rather than weeks.
Doing this in the other order - choosing a managed vector database first, on the assumption of scale that may not arrive - is how teams end up paying a subscription for 40,000 vectors.
If the retrieval layer is going into a product that already exists, AI integration covers where it belongs in the architecture, and pricing shows what moves the cost.
Frequently asked questions
Below roughly a million vectors, usually not a separate one. pgvector inside the Postgres you already run handles that comfortably, and one fewer system to operate, back up and monitor is worth more than a marginal latency improvement nobody will notice.
Around several million vectors, or when you need heavy metadata filtering alongside the vector search, or when index rebuilds start interfering with your transactional workload. The failure is gradual - queries get slower and rebuilds get longer - rather than a wall you hit.
Self-hosted Qdrant or pgvector, by a wide margin, if you already operate infrastructure. Managed services cost more in fees and less in your time, and which is genuinely cheaper depends entirely on what an engineering hour is worth to you.
Far less than people expect. Chunking strategy, the embedding model and whether you re-rank matter enormously; the store matters at the margins. We have never seen a project where switching vector database fixed a relevance problem, and we have seen several where re-ranking did.
Every serious option supports some combination of vector and keyword or filter search now, but the ergonomics differ. If your filters are relational - dates, owners, statuses - keeping vectors next to that data in Postgres is often simpler than synchronising two systems.
Usually a one-off cost measured in tens of dollars for a corpus in the hundreds of thousands of documents, and it is rarely the expensive part. What catches people out is re-embedding: a change of embedding model means regenerating everything, so it is worth choosing one you can live with.
Not sure which your corpus needs?
Tell us the document count, the filters and the growth you expect. We will give you an answer on a free call, including 'stay on Postgres'.