Self-hosting 50 million vectors costs roughly $1,533 a month in reserved compute — and roughly $1,800 a month in the engineer who runs it. The headcount line is bigger than the infrastructure line, and it is the one nobody puts in the spreadsheet.
That is the number that should reframe this decision. Most teams start pricing self-hosted alternatives because a managed invoice went up, then discover that the invoice was never the expensive part. Move off a managed vector database when you have a residency, licence or re-pricing problem. Do not move to save money, because at the scale modelled below it usually does not. Query volume is the one variable that can flip that — managed serverless bills per read while self-hosted compute is flat — so if you are running several times the 30 million queries a month priced here, run the comparison again rather than inheriting this conclusion.
The verdict at 50 million vectors, 1,024 dimensions
All prices checked against the vendors' live pricing pages and public instance pricing on 16 August 2026. The workload is normalised across every option: 50 million vectors at 1,024 dimensions, replication factor 2, 30 million queries per month, 200 QPS at peak, running on a three-node cluster in AWS us-east-1.
| pgvector | Qdrant (self-hosted) | Milvus Distributed | OpenSearch | Chroma | |
|---|---|---|---|---|---|
| Licence | PostgreSQL | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| New moving parts to operate | none | one binary + Raft | message queue + object store + etcd | JVM cluster | one process |
| Vendor's own scale guidance | not stated | shard and replicate | 100M+ vectors | shard and replicate | not stated |
| Modelled infra at this workload | already paid for | $1,533–$4,636/mo | $1,533+ plus dependencies | JVM heap + vector RAM | not viable |
| Point-in-time restore | yes, WAL PITR | no — per-node snapshots | no — backup/restore tool | snapshot repository | manual |
| Indexable dimensions | 2,000 (vector) |
no practical cap | no practical cap | no practical cap | no practical cap |
| Don't pick it if | 3,072-dim embeddings | you need PITR | you have no platform team | you aren't already on it | it's production |
The recommendation: if you already run PostgreSQL, use pgvector and stop shopping. Its operational cost is genuinely near zero because you already pay it — the backups, the on-call rotation, the patch cadence and the restore drill all exist. Nothing else on this list can make that claim. If you do not already run Postgres, the honest cheapest path off a managed vector database is not a self-run cluster at all; it is bring-your-own-cloud (below), which keeps the data in your VPC and the pager on someone else's desk.
The loser here is Milvus Distributed, and not because it is a bad database. It is the most capable system in this comparison and the only one whose vendor documents a path to tens of billions of vectors. But it is the only option that asks you to run a message queue, an object store and a metadata store before you store your first vector, and its own prerequisites page recommends 128 GB of RAM for a cluster and warns that "disk performance is critical to etcd", specifying local NVMe with over 500 IOPS and sub-10ms p99 fsync latency. If you are choosing this to escape a $500 monthly bill, you have chosen a distributed systems project.
What 50 million vectors actually costs to host yourself
The compute bill is decided by one formula and two configuration flags. Qdrant's capacity planning documentation gives the sizing directly: memory_size = number_of_vectors * vector_dimension * 4 bytes * 1.5, where the 1.5 multiplier covers "metadata (such as indexes and point versions) and temporary segments created during optimization."
Run it. 50,000,000 × 1,024 × 4 × 1.5 = 307.2 GB of RAM per copy of the data. At replication factor 2, that is 614.4 GB across the cluster, or about 205 GB per node on three nodes. That needs a memory-optimised instance: an r7i.8xlarge is 32 vCPU and 256 GiB at $2.117/hour on demand. Three of them is $4,636 a month.
Now turn on the two flags most teams never touch.
Scalar quantization drops each dimension from a 4-byte float to a single byte. Qdrant publishes no sizing formula for the quantized case, so extrapolating the same one gives 76.8 GB per copy, 153.6 GB across the cluster, about 51 GB a node. Treat that as the optimistic end rather than a vendor number: the 1.5 multiplier covers "metadata (such as indexes and point versions)", and the HNSW graph links do not shrink when you quantize, so the true figure sits above it. Qdrant also stores "quantized vectors ... alongside the original vectors in the collection" — the originals move to disk, they do not disappear. Even at the pessimistic end this still lands on an r7i.4xlarge at 16 vCPU, 128 GiB and $1.058/hour. Three of those is $2,317 a month. This is not an exotic technique: OpenSearch documents that 7-bit vectors from its Lucene scalar quantizer "use only 25% of the memory required by 32-bit vectors", and Milvus 2.6 ships 1-bit RaBitQ quantization that its own team measured at 72% memory reduction when paired with an optional SQ8 refinement step.
Reserved instances take the r7i.4xlarge to $0.700/hour on a one-year commitment. Three nodes: $1,533 a month.
Same 50 million vectors, same replication, same query volume. $4,636 down to $1,533 — a 3x swing decided entirely by two settings, before you have compared a single vendor. Neither is a secret and neither is on anybody's comparison page, because neither is a product feature.
A definition worth pinning down, because it is where the savings live: scalar quantization is the practice of storing each vector dimension at reduced precision — typically one byte instead of four — trading a small amount of recall for a 4x reduction in the memory the vectors occupy. Qdrant puts the error it introduces at "usually less than 1%", and note that the vectors are what shrink — the index graph on top of them does not. You measure the recall loss on your own eval set. You do not take the vendor's word for it.
What the $1,533 does not include: block storage for the raw vectors and snapshots, cross-AZ traffic, a load balancer, and the staging cluster you will need in order to test an upgrade without testing it in production. Budget for a second environment or accept that you will upgrade blind.
The headcount line nobody puts in the spreadsheet
The engineer costs more than the servers, and this is the finding that decides the question. The 2025 Stack Overflow Developer Survey puts the median cloud infrastructure engineer at $103,112.50 a year globally — self-reported, and only from the 48.8% of respondents who answered the pay question. That global median is deliberately the conservative end: the same survey puts the US median for the role at $189,000. Fully loaded — benefits, payroll tax, equipment, the share of a manager — call it $145,000 in a mid-cost market.
Give the vector cluster 15% of one engineer. That is $21,750 a year, or about $1,800 a month — slightly more than the tuned $1,533 infrastructure bill. Do not lean on the precision of that ratio: the $1,533 leaves out the storage, traffic and staging cluster listed above, and a US-based owner would push the human line past $3,000 a month on its own. The direction is the durable part, and it is the same in every version of this arithmetic.
Fifteen percent is not a conservative estimate. It is roughly six hours a week, and it buys: version upgrades, index rebuilds after an embedding model change, capacity forecasting, snapshot verification, the quarterly restore drill, responding to the alert that fires because a segment merge blew through memory, and answering the security team's questions during the annual audit. It does not buy schema design or query tuning, which your application engineers were doing anyway.
The distribution is what actually hurts. This cost is not six hours every week — it is zero hours for eleven weeks and a lost week in the twelfth, and the twelfth week is never a week you scheduled. A managed service converts a lumpy, unplannable cost into a flat one. That is most of what you are buying, and for a team of five engineers it is often worth more than the difference on the invoice.
Run the number honestly before you move. If your answer to "who owns this cluster" is a name and that person is already at capacity, you have not found a saving. You have found a queue.
The scale ceiling is a memory ceiling, and it moves
Every option here has a ceiling, and in each case it is the point where the index stops fitting in RAM. What differs is what happens when you hit it.
pgvector's ceiling is the sharpest and the most specific. Its HNSW index supports vectors up to 2,000 dimensions for the standard vector type and 4,000 for halfvec. If you standardised on OpenAI's text-embedding-3-large at 3,072 dimensions, you cannot build an HNSW index on the default type at all — you must store as halfvec or reduce dimensionality. That is a hard architectural constraint discovered late by a surprising number of teams. The build path has its own trap: pgvector notes that indexes "build significantly faster when the graph fits into maintenance_work_mem", and on a default-configured instance a 50-million-row build will page to disk and run for hours.
For Postgres shops that outgrow pgvector's index but not Postgres itself, pgvectorscale adds a StreamingDiskANN index under the PostgreSQL licence, with vendor-published benchmarks of 28x lower p95 latency and "75% less cost when self-hosted on AWS EC2" against Pinecone's storage-optimised index on 50 million 768-dimension embeddings. Treat those as the vendor's own numbers on the vendor's own benchmark — they are a reason to run your own test, not a reason to skip one.
Qdrant's ceiling is elastic but not free. You can move vectors out of RAM onto memory-mapped files, and the documentation is refreshingly blunt about the price: "if you store half as many vectors in RAM, search latency will roughly double." That is a knob, not a wall — which makes it the most forgiving option here for a workload that grows unpredictably.
Milvus is the only one whose ceiling is genuinely high, and it charges for it in components. Its documentation splits deployment into Lite for "up to a few million vectors", Standalone for "up to 100 million", and Distributed for "100 million up to tens of billions" — and states that every instance beyond Lite "relies on a message queue, object storage, and a metadata store." Milvus 2.6 improved this materially by replacing external Kafka or Pulsar with a purpose-built WAL called Woodpecker, which removes the single hardest dependency to operate. It does not remove etcd or the object store.
Chroma's ceiling is the reason it is on this list. It is Apache 2.0 and genuinely excellent for local development and prototypes, and its documentation publishes no scale guidance because that is not what it is for. Use it to build. Do not use it to serve 200 QPS against 50 million vectors.
Restoring the index at 2am is where this is actually decided
Backup and disaster recovery is the single biggest quality gap between these options, and it is the one no comparison table shows you. The question is not "does it have backups." Every one of them has backups. The question is what you can restore and how precisely.
PostgreSQL's continuous archiving supports true point-in-time recovery: "it is possible to restore the database to its state at any time since your base backup was taken." A bad migration at 14:07 is recoverable to 14:06. pgvector inherits this for free, along with every backup tool, runbook and restore drill your DBAs already have.
Nothing else on this list offers that. Qdrant snapshots are tar archives of "data and configuration of a specific collection on a specific node" — and the documentation states plainly that "in a distributed setup, when you have multiple nodes in your cluster, you must create snapshots for each node separately." Full storage snapshots are "only suitable for single-node deployments." Restores are also version-constrained: a snapshot restores only to the same minor version or the next one, so a cluster three versions ahead of your archive cannot read it.
Read that twice, because it is the operational reality of self-hosting a distributed vector database. Your backup is N separate files taken at N slightly different moments, and your restore is a coordinated multi-node procedure that you have to write, schedule, and rehearse. Milvus Backup is a well-built CLI and API for "backup and restore of metadata, segments, and data across Milvus instances" — and its documentation makes no claim of point-in-time recovery.
For a derived index this is often acceptable: if you can re-embed from a source of truth, your real RPO is the cost of a full re-index, not the age of your last snapshot. So answer one question before you choose. How long does a full re-embed and re-index of 50 million vectors take, and what does it cost in inference? If the answer is "six hours and $4,000", your snapshot strategy can be casual. If the answer is "we no longer have the source documents", it cannot, and you should be on something with PITR.
When self-hosting is the wrong answer
Say who should not buy each option, including the one you are recommending. Here is the honest list.
- Do not self-host anything if you cannot name the person who restores the cluster at 2am. Not the team — the person. If that name is your best engineer and they are already the answer to three other questions, the managed bill is cheaper than the attrition.
- Do not self-host if your data partitions cleanly by tenant. Managed per-namespace pricing collapses under that shape — Pinecone bills a documented minimum of 0.25 read units per query regardless of corpus size once a namespace is small, at $16–$18 per million read units on Standard. We ran that arithmetic in full in our Pinecone, Weaviate and pgvector comparison, and the conclusion holds: a genuine tenant key makes managed vector search very cheap, and no amount of self-hosting beats it.
- Do not pick pgvector if you are on 3,072-dimension embeddings and unwilling to move to
halfvec, or if your working set will not fit an instance you are willing to pay for. - Do not pick Qdrant self-hosted if your compliance posture requires point-in-time restore of the vector store itself rather than of an upstream source of truth.
- Do not pick Milvus Distributed without an existing Kubernetes platform team and an on-call rotation that already covers stateful services.
- Do not pick OpenSearch unless you are already running it. Adding a JVM cluster to your estate for vector search alone is the most operationally expensive way to arrive at this answer — though if it is already there, the vector plugin is close to free and the licence risk is lower than it looks, since Elastic itself added AGPL as a licence option in August 2024 after the 2021 move to SSPL and ELv2.
- Do not read a headline managed price as your price. Weaviate's Flex tier starts at $0.00465 per million vector dimensions per month with a $45 monthly minimum — but that is a floor, and the vendor's own pricing explainer says dimension count is "further multiplied by the replication factor" and that the rate "varies by the index type (HNSW vs Flat) and compression". At replication factor 2, our workload is 102.4 billion dimensions. Price your actual index type, not the marketing floor.
One more thing that is easy to miss: the managed vendors do not all publish a unit rate. Qdrant's pricing page advertises a free tier of 0.5 vCPU, 1 GB RAM and 4 GB disk, then routes Standard to a calculator and Premium and Hybrid Cloud to a sales conversation. A price you cannot look up is a price that can be renegotiated at renewal, and that is itself a legitimate reason to hold the option to self-host — even if you never exercise it.
The middle path most teams should take instead
Bring-your-own-cloud is the answer to the residency problem without the answer to the pager problem, and it is under-considered. In this model the data plane runs in your VPC on your account, holding your vectors and indexes, while the vendor's control plane handles upgrades, scaling and monitoring over an outbound connection.
Qdrant Hybrid Cloud runs clusters in your own Kubernetes and states that "the Qdrant Cloud only receives telemetry through an outgoing connection. No access to databases or your Kubernetes API is necessary." Zilliz Cloud BYOC does the same for Milvus. Its documentation puts the Milvus instance, the object storage bucket and the monitoring stack inside your VPC on AWS, GCP or Azure, with the upgrade workflow and resource scheduler on Zilliz's side reachable only over "encrypted outbound-only TCP connections on port 443".
If your reason for leaving managed hosting is a data residency rule, a sovereignty requirement or a security review that will not approve a third-party datastore, this satisfies the requirement and skips the distributed systems project. It does not satisfy a licence-independence requirement — you are still on a commercial contract, and the renewal leverage question does not go away. Both vendors quote it through sales, which tells you what to expect.
For the wider version of this argument, we worked through the same residency-versus-convenience trade for model providers in our review of OpenAI alternatives for sensitive workloads, and the same pattern holds one layer down the stack.
What actually predicts regret here
Four questions predict whether you will be happy with this decision in eighteen months. Nothing else on the evaluation grid comes close.
- Does your corpus have a tenant key? If yes, managed serverless is very likely cheaper than anything you can run, and the analysis is over.
- Can you re-embed from a source of truth? If yes, weak backup semantics are survivable and Qdrant or Milvus are fine. If no, you need PITR and you should be on Postgres.
- Is your embedding dimension above 2,000? If yes, pgvector's default index type is out and the shortlist changes.
- Who is on call? If the honest answer is "we would figure it out", you are buying an incident, not a database.
This week: compute your actual memory requirement with the Qdrant formula and your real dimension count, then price the instance that holds it. Most teams discover their index is either far smaller than they feared or does not fit at all, and both answers end the debate quickly.
This month: run a scalar-quantization test against your own eval set and measure the recall delta. A 4x memory reduction at 1% recall loss changes your instance class and your entire cost model. Refusing to test it costs you 3x.
Before your next renewal: rehearse a restore. Not a snapshot — a restore, into a fresh cluster, timed, by someone who did not write the runbook. That exercise, not the pricing page, is what tells you whether you can operate this.
The Bottom Line
The vector database is the wrong place to look for savings and the right place to look for control. Its share of an AI platform budget is small next to inference — a point we made when DeepSeek signalled a price rise and again when comparing gateways for multi-provider cost control — and the operational cost of running one yourself is disproportionate to what it saves.
But the same technology cycle that made "just use the managed service" the correct default for a decade also produced the 2021 Elasticsearch relicensing, and every team that had built on the assumption that the licence would not change learned the same lesson at the same time. Apache 2.0 on Qdrant, Milvus and Chroma is not a cost advantage. It is an option on your own future, and it is worth holding whether or not you exercise it.
Self-host because you need the data to stay somewhere specific, because you need a licence nobody can change under you, or because you want a credible alternative on the table at renewal. Those are good reasons and they justify the headcount.
Do it to save $500 a month and you will pay for it in engineer-weeks you did not budget.
Continue Reading
- Pinecone vs Weaviate vs pgvector: Stay on Postgres
- Best RAG Platforms for Regulated Industries: Permissions First
- Best LLM Gateways for Cost Control: Self-Host First
- 7 OpenAI Alternatives. Only 3 Clear a Sovereignty Rule.
- MongoDB 8.3 Kills the 4-Database AI Agent Stack
- DeepSeek Will Raise Prices. Your Ceiling Is Already 4x.