What does a vector database cost to run yourself, with a partner or as a managed service?
A team that wants RAG or semantic search needs to know what the three routes really cost. The engine license is free for the open-source code of Qdrant, Milvus and Weaviate, so the cost is infrastructure, labor and operations, and it depends on vector count, embedding dimensions, query rate and how much high availability the workload requires. Qdrant's documentation states that the open-source engine is free to self-host, but running it is not free: the company's pricing and installation pages make the operating model the real decision.
Managed routes price differently. Qdrant Cloud offers a free single-node tier with 0.5 vCPU, 1 GB RAM and 4 GB disk, a usage-priced Standard tier and a Premium tier with a minimum spend. Qdrant Hybrid Cloud and Private Cloud are priced through Qdrant sales. Zilliz Cloud offers Serverless, Dedicated and bring-your-own-cloud options for Milvus, and Weaviate Cloud is a separate managed offering. Confirm with each vendor how they bill for memory, storage, replicas, backups and egress, because the same workload can produce very different invoices. Self-hosting also brings recurring costs that a managed plan absorbs: patching, on-call coverage, re-indexing after embedding model changes and restore testing.
Ask every bidder for a quote built from written scope, not a list price. The quote should state the vector count and dimensions at launch and at planned growth, the replication factor, the number of nodes needed for quorum, the expected query rate, backup retention, and who performs upgrades and restore tests. Qdrant's distributed deployment guidance recommends at least three nodes for production, so a highly available self-hosted cluster has a floor on hardware before any workload is added. DeployOpen does not estimate prices; quotes follow from the scope agreed in writing before work starts.
Which cost components apply to in-house, partner and SaaS routes?
This table compares who pays for each cost component of running a vector database in-house, through an implementation partner, or on a commercial SaaS service. Read the one-time and recurring notes first, then the sizing drivers, since replication and node count often matter more than the license line. The main takeaway is that self-hosting moves cost from the vendor invoice into memory, storage and operating effort that you must budget and staff.
| Component | In-house | Implementation partner | Commercial SaaS |
|---|---|---|---|
| Memory-heavy nodes | Recurring: you buy or rent nodes sized for vector count, dimensions and index type. Qdrant needs block storage, not NFS or S3, so plan SSD or NVMe. | One-time: sizing and load testing in the written scope. Recurring: the infrastructure you own still bills monthly. | Recurring: usage or tier pricing from the vendor. Ask which node sizes and memory limits the quote assumes. |
| Replicas and nodes for quorum | Recurring: Qdrant's distributed docs recommend at least three nodes for production so quorum survives a node failure. Each extra node is extra capacity. | One-time: cluster design. Recurring: the same node count, plus any support retainer you sign. | Recurring: replicas are usually bundled in the tier. Confirm what availability terms apply to your tier. |
| Storage and replication factor | Recurring: the replication factor duplicates data. Per the Qdrant distributed deployment docs, a factor of 2 doubles storage. Budget snapshots and backups separately. | One-time: storage design. Recurring: the same storage bill plus backup retention. | Recurring: storage is metered or bundled by tier. Ask how snapshots and backup copies are charged. |
| Re-indexing and re-embedding | One-time per change: rebuilding indexes after a dimension, model or quantization change. Engineering time and extra temporary capacity are the main costs. | One-time: planned re-embedding as a fixed-scope task. Ask whether the price covers reprocessing the full corpus. | One-time or recurring: some vendors bill re-indexing as compute. Confirm the metering before you commit. |
| Engineering and on-call | Recurring: staff for upgrades, monitoring, scaling and incident response. This is often the largest line and is easy to undercount. | One-time: build and handover. Recurring: optional retainer for upgrades, monitoring and support. | Recurring: lower operating load, but you still own schema design, access rules and integration work. |
| Security and compliance evidence | One-time: enabling authentication, TLS and per-collection permissions, then documenting them. Recurring: log review and access reviews. | One-time: hardening and evidence preparation. Note that DeployOpen prepares evidence but auditors issue any reports. | Recurring: depends on the vendor's attestations and which controls you must still configure yourself. Ask for the current report. |
| Backup and restore testing | Recurring: scheduled backups and periodic restore tests. Qdrant snapshots need version-matched restores, so test them. | One-time: backup design and a restore drill. Recurring: retainer for repeated tests. | Recurring: included backups vary by tier. Ask for the restore time objective in writing and whether restores are tested. |
| Upgrades and version management | Recurring: testing and rolling out each release. Qdrant's Helm chart lacks zero-downtime upgrades and automatic shard rebalancing, which adds work. | One-time: upgrade runbook. Recurring: upgrades under a retainer, if agreed in writing. | Recurring: largely handled by the vendor, though you still test client compatibility. |
What moves the cost up or down
Vector search cost follows a small set of inputs: how many vectors you store, how large each vector is, how often you query, how much redundancy you keep, and which deployment mode you choose. Each card below names what pushes the bill up, what brings it down, and what to confirm before you compare a self-hosted build with a partner-run or managed option.
Vector count and memory footprint
The number of vectors is the first driver because index structures such as HNSW are typically held in memory for fast search. More documents, smaller chunks and frequent re-chunking all multiply the vectors you must store. Lower cost comes from chunking policy, deduplication and removing expired or superseded content before embedding. Ask any vendor or partner to size memory from your vector count and chunk strategy, and to show the disk and RAM assumptions behind that sizing.
Embedding dimensions
Higher-dimensional embeddings consume more memory and disk per vector and slow each similarity comparison. Switching to a smaller embedding model or applying quantization can reduce footprint, but changes retrieval quality and usually forces a full re-embedding and re-index. Before committing, measure recall at the dimensions you plan to use, and confirm whether your platform supports compression such as quantization or memory-mapped files for the index type you choose.
Query rate and concurrency
Query volume determines how many CPU cores and replicas you need to hold latency steady during peaks. Costs rise with concurrent users, agent loops that issue many searches per request and reranking passes. Costs fall when you cache frequent queries, limit top-k results and batch background searches. Ask how each option prices or scales by queries per second, and whether the figure in your quote assumes peak or average load.
Replication and high availability
Replication multiplies storage and compute. In Qdrant distributed mode, a replication factor of 2 doubles storage, and production clusters are typically sized with at least three nodes so quorum survives a node failure. Costs fall if you accept a lower availability target for non-critical collections and enable replication per collection rather than cluster-wide. Ask whether the quote includes standby capacity, backup storage and the time needed to restore.
Filtering and hybrid search needs
Metadata filters, keyword (BM25) search and reranking add index work, memory and query time. Entitlement-aware filtering, where each user only retrieves what they may see, is often the most expensive filter pattern because it must run on every query. Costs go down when filters are designed around indexed payload fields and when the platform handles hybrid search natively instead of across two systems. Confirm how each candidate engine indexes filtered fields and what it costs to run hybrid search at your query rate.
Licence and deployment mode
The deployment mode decides who runs the cluster and who you pay. Qdrant Hybrid Cloud and Private Cloud are priced through Qdrant sales, while Zilliz Cloud offers Serverless and Dedicated options. Serverless usually shifts cost toward usage, while Dedicated and self-managed deployments shift it toward reserved capacity, staff time and on-call support. Request a written breakdown of licence fees, infrastructure, support hours and exit costs, and confirm where your data and backups physically sit.
Why memory, replicas and storage dominate the bill
Vector count and dimensions set the footprint before anything else is configured. Every stored vector takes space in proportion to its dimension count, and the index structures built over those vectors add to it. Doubling the dimensions of an embedding model roughly doubles the raw vector storage, and a vector store that keeps its index in memory for fast search needs RAM that scales the same way. Ask your vendor or partner to show the sizing arithmetic for your own vector count, dimension, index type, quantization setting and payload size, and to state which of those numbers are held in RAM and which on disk. A sizing that only gives a total without this split is hard to check.
In Qdrant, the replication factor multiplies what you pay for storage. The distributed deployment documentation explains that collections are split into shards across nodes and that extra copies are kept through a replication factor, which doubles storage at a factor of 2. The same documentation recommends at least three nodes for production so quorum survives a node failure and a shard count that is a multiple of the node count. Those three nodes are a sizing decision with a cost, not a default. Confirm with your partner how many nodes, shards and replicas the proposal assumes, and what the cluster looks like after one node is lost.
Qdrant and Milvus both need fast local block storage. Qdrant's installation documentation says it needs block-level storage with a POSIX-compatible file system, cannot run on network file systems such as NFS or object storage such as S3, and recommends SSD or NVMe drives. Milvus separates compute from storage, so its object store (MinIO, S3 or Azure Blob), its metadata store (etcd) and its write-ahead log (Woodpecker, Kafka or Pulsar) are extra components to size, back up and operate. The Milvus architecture overview lists these dependencies. Ask for a bill of materials that names each of them, who runs them, and whether their licensing and support are included in the quote.
How to build your own vector database cost estimate
This sequence turns vague ideas about vector search into a written scope that you can price in the same way for self-hosting, a partner-run deployment and a managed service. Each step produces a figure or decision that the next one depends on.
Define vector count, dimensions and growth
Start by counting the chunks or records you expect to embed at launch and over the next planning horizon your business owners agree on. Record the embedding model's output dimensions, because the dimension count and the number of vectors together set the raw memory and disk footprint for each collection. Ask the team that owns the embedding pipeline to confirm how often documents change and how many vectors each change creates. The step is done when you have a table of collections, vector counts, dimensions and expected growth that engineering and finance both accept.
Set query rate and latency targets
Measure or estimate the peak queries per second each application will send, including batch jobs and retrieval calls from any AI assistant in front of the store. Write down the latency target for the ninety-fifth percentile that users or downstream services need, and whether searches combine vector similarity with metadata filters or keyword matching. Query rate and filter complexity drive how many CPU cores and how much memory each node needs, so these numbers decide the node sizing that the later cost lines depend on. The step is done when each workload has a signed-off query rate and latency target.
Choose replication and availability levels
Decide which collections need high availability and how many copies of each shard the business requires. Replication multiplies storage and memory, so a replication factor of 2 roughly doubles the storage that the replica count adds to the base footprint, and production clusters need enough nodes for quorum to survive a failure. Record the recovery point and recovery time objectives that the business agrees for each collection, since they determine backup frequency and standby capacity. The step is done when each collection has a replication setting, a node count and documented recovery objectives.
List the storage and backup footprint
Add up primary storage, replica storage, snapshot retention and backup copies in the location your data rules require. Confirm that the chosen engine runs on block storage with a POSIX-compatible file system, since some options cannot use network file systems or object storage for their primary data, and price fast SSD or NVMe volumes accordingly. Include retention for snapshots and off-site copies, and note that deleted records must also be removed from backups where your policy requires it. The step is done when you have a storage bill of materials by environment, including backup retention periods that compliance has approved.
Cost the engineering and on-call load
List the people who will install, upgrade, tune, monitor and restore the vector store, and estimate the hours each function needs per month based on your own staff. Include the on-call rota for the store, the work to re-embed content when the model changes, and the testing needed before each upgrade. Separate one-time costs such as initial deployment, integration and hardening from recurring costs such as patching, monitoring, capacity reviews and support retainers. The step is done when the team lead has signed off monthly and one-time labor lines, each tied to a named role.
Add security and audit logging work
Scope the controls the store must have before it holds production data: API keys or identity-based access, role or collection permissions, TLS on REST and gRPC, network restriction, and audit logging of authenticated operations. Estimate the configuration, testing and log retention work for each control, and the ongoing cost of storing and reviewing logs. Ask your security team to confirm which controls become required evidence for your assessments. The step is done when security has approved a control list and each control has an owner and a cost line.
Request quotes against the same written scope
Send the same written scope, covering the collections, vector counts, dimensions, query rates, replication settings, backup rules, security controls and support expectations, to each option you are considering. Ask self-hosting teams, implementation partners and managed service vendors to state which items they include, which they exclude, and what recurs after go-live. Compare the quotes line by line against your cost model, and ask each vendor to explain how the price changes if vector count or query rate doubles. The step is done when every option has answered the same scope and you can see the one-time and recurring totals side by side.
What is one-time and what recurs every month
The first cost question is which part of the total is paid once and which part keeps arriving. One-time work covers architecture and sizing, the initial deployment, hardening (authentication, TLS, per-collection permissions and audit logging), integration with the embedding pipeline, restore testing, and the documentation that auditors and your own operations team will read later. In a self-hosted model, that work is usually a mix of your platform engineers' time and any implementation partner's fixed-scope fee, agreed in writing before work starts. Ask each party to list those activities separately so you can see what you will not pay for again.
Recurring costs are the ones to model over three to five years, not just the first quarter. They include the infrastructure itself (memory-heavy nodes, replicas, block storage on SSD or NVMe), upgrades and security patches, monitoring and on-call coverage, and backup runs with periodic restore tests. Re-embedding deserves its own line: when the embedding model changes, every vector in the collection may need to be regenerated, which consumes compute and creates a second copy of the data during the switch. The open-source engine carries no license fee. Qdrant's pricing page states the engine is free to self-host, and its Cloud free tier provides 0.5 vCPU, 1 GB RAM and 4 GB disk, which is useful for pilots but not a production sizing benchmark.
For managed services, the recurring line is a subscription or usage charge, so the question shifts from who runs the hardware to what each month of usage costs. Confirm with each vendor how usage is metered (storage, compute or query volume), whether uptime commitments and SSO carry a higher tier, and whether an enterprise deployment needs a minimum spend. Also ask what happens to your data and fees if you exit. Whatever model you choose, request a quote that separates one-time items from monthly items and states which recurring costs you own regardless of provider.
Vector database cost questions buyers ask before hiring help
What drives the cost of a self-hosted vector database the most?
Memory and storage sizing, followed by replicas and the people who run the cluster, usually matter more than the license, because the open-source engines are free to self-host. Vector count and dimensions set how much RAM and disk the index needs, so a collection that grows from millions to tens of millions of vectors changes the node size and count. Replication multiplies storage: in Qdrant, the replication factor of 2 doubles storage. Query rate adds CPU and may require more replicas to keep latency steady. Ask any provider to show the memory and disk arithmetic for your vector count, dimension size and replication setting, in writing.
Is a managed vector service cheaper than running Qdrant or Milvus ourselves?
It depends on scale, uptime requirements and who carries the operations work, so neither option is cheaper in every case. Qdrant Cloud has a free single-node tier with 0.5 vCPU, 1 GB RAM and 4 GB disk, and a usage-priced Standard tier with a 99.5% uptime SLA, which can suit small workloads. Qdrant Hybrid Cloud and Private Cloud are priced through Qdrant sales, and Zilliz Cloud offers Serverless, Dedicated and bring-your-own-cloud options. Compare the managed bill with your own cloud compute, storage, backup, monitoring and on-call hours, and check whether the service runs inside your residency and access boundary.
Can our team run a self-hosted vector database without a partner?
A team with Kubernetes, backup and security experience can run one, but the work goes beyond installing a container. Qdrant's security documentation states that self-deployed instances listen on all network interfaces and have no authentication configured by default, so hardening comes first. Qdrant's documentation also notes that the community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, which affects upgrade planning. Assess your team's skills in these areas, then decide which parts to keep in-house and which to contract out.
How long does setting up a self-hosted vector database take?
The timeline depends on the number of data sources, the embedding pipeline, the authentication model and the environment, so no fixed duration applies across projects. Work usually includes sizing, deploying a cluster, configuring TLS, API keys or role-based access, backup and restore testing, and connecting the embedding pipeline. Qdrant recommends at least three nodes for production clusters so quorum survives a node failure, which adds infrastructure lead time if your cloud accounts or hardware are not ready. Ask for a written scope with milestones and a list of client dependencies before agreeing on dates.
What do we need to provide for a vector database project?
The client supplies infrastructure, identity and data ownership, and the project cannot proceed without them. On infrastructure, Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on network file systems such as NFS or object storage such as S3, with SSD or NVMe drives recommended. For identity, you need to decide how users and services authenticate, which may mean connecting to an existing identity provider or issuing API keys. Data owners must confirm which sources may be embedded, retention rules for derived vectors, and who approves deletion when source records change.
What should we ask for in a vector database quote?
Ask for a written scope that lists deliverables, environments, sizing assumptions and exclusions before comparing numbers. Request the sizing basis, including vector count, dimensions, replication factor and expected query rate, and the node count and storage type it produces. Separate one-time costs, such as deployment, hardening and migration, from recurring costs, such as infrastructure, backup storage, monitoring, upgrades and support retainers. Confirm how restores are tested, what happens when the engine or model changes, and which items depend on your cloud or hardware budget. Quotes from DeployOpen follow from the written scope and are not published as a price list.
How to compare a partner quote with a SaaS invoice
A fair comparison puts the same scope, vector count, dimensions, query rate, availability target and compliance evidence on both sides before any totals are read. A SaaS invoice covers the service only. It does not include your internal security review, the work to prove data residency for the embedding pipeline, the audit evidence you collect for an assessment, or the engineering time to rotate keys and respond to alerts. A partner quote, by contrast, should list those items explicitly. If one side covers a three-node cluster with backups tested quarterly and the other covers a single managed tier with no stated uptime commitment, the gap is in scope, not price.
Ask the partner for written sizing assumptions: the vector count at launch and at the planned growth point, the embedding dimensions, the index type, the expected memory and disk per node, the replication factor and the peak query rate. Ask the vendor for the same assumptions behind its invoice, including which tier or uptime commitment it assumes. Confirm which vendor documentation the sizing relies on, since the Qdrant distributed deployment docs recommend at least three nodes for production clusters so quorum survives a node failure. A quote that omits replicas or node count is not comparable to one that includes them.
Request four items in writing before signing. First, handover documentation: architecture diagrams, runbooks, configuration files and the list of credentials and where they are held. Second, backup and restore test results, including the date of the last restore into a clean environment and the version used for it. Third, support hours and response expectations, with named escalation paths. Fourth, upgrade responsibility: who applies patches, who tests them, who owns rollback and who pays for them after year one. Those four answers determine whether the self-hosted figure carries recurring cost that the SaaS invoice never shows.
How DeployOpen scopes and delivers a fixed-scope vector database implementation
DeployOpen plans, implements, hardens, documents and supports self-hosted vector databases inside the client's own cloud accounts, data centers or air-gapped networks. For cost decisions, we start with a written scope that sizes the vector count, dimensions, query rate and replicas, so the self-hosted, partner and managed options can be compared on the same assumptions.
How we scope
- Agree the vector count, embedding dimensions, growth rate and expected query rate before any cost model is built.
- Document which engine is in scope, such as Qdrant, Milvus, Weaviate or pgvector, and why it fits the workload.
- Set out in writing the replicas, backup retention, staging environment and on-call hours the proposal assumes.
How we build
- Size memory, block storage and replica nodes against the agreed scope, and record the sizing assumptions for review.
- Enable authentication, TLS and per-collection permissions before any data is loaded, since Qdrant ships without authentication by default.
- Test snapshot restores and re-indexing time on representative data so the cost model reflects measured behavior, not guesses.
How we hand over
- Deliver runbooks for scaling, upgrades, re-embedding and restores, with the cost drivers and their owners named.
- Provide a cost register listing one-time setup items and recurring infrastructure, licence and support costs.
- Walk your platform and security teams through monitoring, alerting and the evidence an internal auditor would sample.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer once the platform is in production.
- Review vector growth and query load against the original sizing, and flag cost changes before they reach the budget.
