The same holds however you reach Qdrant, whether from application code or through a workflow tool: the cluster underneath is billed the same way. **Replication and memory sizing decide what you pay**, and neither appears in a plan name. ## Week one: a free cluster that stopped fitting Within the first week, the illustrative support-search prototype outgrew its free cluster, and the cause was the ceilings and absences in the free tier, not any price. The team indexed past support tickets and help-centre articles, then pointed a small internal search tool at the cluster. ### What the free cluster includes For this prototype, the documented free-tier limits are set out in the exhibit below: - a fraction of a vCPU - a small allowance of RAM - a small disk - a single node - inactivity rules - a list of paid features that are absent Treat it as a budget for the workload, not as a feature list. One line matters most. A single node means the cluster has no second copy of the data, so the replication discussed earlier is unavailable here by construction. ### Where the free cluster ran out First the memory went. Vectors, an index and the payload fields attached to each ticket all compete for the same small allowance, and the prototype's corpus grew faster than its builders expected. Search latency became uneven, which is how an undersized cluster usually announces itself.  Second came the inactivity rules. Quote the clause as written before relying on it, because a support tool that goes quiet over a weekend is exactly the pattern such a rule targets. Third came the missing features: if the pilot needed them, the only route was a paid one. ### Qdrant free cluster data loss and deletion **Treat everything on the free cluster as disposable until you have confirmed, in the terms, what happens on suspension or deletion.** **If the vendor's cloud has an outage, or the vendor reclaims your cluster while its cloud is fine, a single node gives you nothing to fail over to.** In practice, keep the source tickets and the embedding script outside the cluster. Rebuilding then costs compute time, not the corpus, and that cost belongs in the sizing exercise before you choose a paid plan. ## Estimating your Qdrant bill by RAM and scale **Count RAM, not vectors**: the invoice tracks the RAM your vectors occupy, not the vector count itself. The same 1536-dimension corpus costs very different amounts depending on how you store it and how many copies you keep running. ### Sizing the RAM before the price At 1M vectors, float32 needs 3.75 GB of RAM, according to the [VePrompts RAG architecture calculator](https://veprompts.com/tools/rag-architecture-calculator/vector-db/qdrant/). At 10M it needs 37.5 GB, so the smallest paid node stops being enough somewhere between those two sizes. The chart shows how far quantization pulls both figures down, and the takeaway is that int8 and binary cut the footprint by roughly 2.6x and 5x at either scale, so model size becomes tractable even for systems with limited storage budgets. With int8, the two sizes drop to 1.45 GB and 14.5 GB. According to the VePrompts RAG architecture calculator, binary brings them to 0.7 GB and 7.02 GB, which could keep 10M vectors on a node that float32 would overflow.  Memory scales linearly per the VePrompts RAG architecture calculator, so 50M vectors at float32 implies about 187.5 GB (5 × 37.5), a multi-node cluster before any replica is added. Quantization trades recall for memory, so test it on your own queries before you size around it. ### Qdrant replication and backup costs Add a replica and you add a full additional copy of the memory footprint. A 10M-vector int8 collection at 14.5 GB becomes 29 GB with one replica, and the bill doubles for that reason alone. Ask what a single-replica deployment does when its node or its cloud zone fails, because the answer is downtime or a restore, not degraded service. Once backups are on, they add storage charges and a restore time. A snapshot you haven't restored is an untested control, so budget a restore drill. ### Egress, support and cloud region You pay for data leaving the cluster separately from compute. If your application runs in a different region or provider from the vector database, every query response crosses that boundary, and you pay for it on every request. When the cluster is down, the support tier decides who answers and how fast. Read the response-time terms of each plan line by line, and check whether they apply to your plan or only to a higher one. Region choice also affects price and latency, so fix it before you compare plans. ## Self-hosting and the closest alternatives, priced Pay least by self-hosting Qdrant and you carry the highest operations burden; the managed rivals bill on usage, and pgvector is cheapest only where Postgres already runs. With the region fixed, the table below shows what drives each bill and who does the work. | Option | Pricing model | Free tier | Entry paid price | What scales the bill | Operations work | |---|---|---|---|---|---| | Self-hosted Qdrant | Server rental | Software's free | One VM | RAM per node | Yours entirely | | Pinecone | Usage-based | Starter tier | Usage above free | Storage, reads, writes | Vendor | | Weaviate Cloud | Subscription | Trial cluster | Cluster plan | Vectors and dimensions | Vendor | | Zilliz Cloud | Usage or dedicated | Free tier | Usage above free | Compute units, storage | Vendor | | pgvector | Postgres instance | Extension's free | Your database bill | Instance size | Yours, shared with Postgres | ### Self-hosted Qdrant: servers and engineer time On a 16 GB VM, the bill is [$101.49 a month at Hetzner, $113.43 at GCP, $126 at DigitalOcean and $140.16 at AWS](https://spendark.com/instances/), so **AWS charges about 38% more for identical memory**.  Scale to 64 GB and [the ranges widen to $325 at Hetzner, $392 at GCP, $560 at AWS and $724 at DigitalOcean](https://spendark.com/blog/cloud-tax-price-comparison-2026/), which means DigitalOcean costs more than double Hetzner. Provider choice matters more as the index grows. None of these figures includes the engineer who patches, backs up and answers the page when a node dies. Three vendors, three units: Pinecone, Weaviate and Zilliz each bill a different one, so the same vectors produce three different invoices. Ask each vendor what happens to your queries during its outage, and whether your contract credits you for it. With pgvector, the extension adds no licence fee, and your existing backups and failover cover it. The cost appears when vector memory competes with transactional workloads and forces a larger instance. ## Qdrant ingestion workflows with Activepieces To stop re-embedding every document on every sync, a team can build a deterministic workflow in Activepieces, with triggers, branches and a schedule, keep its own record of synced items in the built-in Tables, and put the embedding and Qdrant calls in the same flow. The team writes the comparison logic itself; nothing here detects changes on its own. **The run is the meter**: Activepieces charges 1 credit per flow run, whether the sync holds two steps or ten. Zapier's pricing page bills per task and Make's per module, so on those meters splitting a sync into small, separate steps costs extra; here the check, the embed, the upsert and the delete cost the same as one blunt step. That lowers embedding spend and write load. It doesn't change what Qdrant charges. On each sync, the team in question ran a full re-embed. Every run paid for embeddings on documents that hadn't changed, then overwrote identical points in the collection. ### Syncing only changed documents into Qdrant To compare, the check needs something to compare against, such as a content hash or an updated-at timestamp stored with each point's payload. An upsert in Qdrant replaces a point with the same ID, so a stable ID derived from the source record keeps edits from piling up as duplicates. ### Deleting stale vectors from Qdrant The same workflow has a second branch: records that no longer exist in the source go to a Qdrant delete. This matters for cost as much as for correctness. A deleted document whose vector remains still occupies memory in the collection, and it can still come back in search results. Removing it frees capacity you're otherwise paying to hold, and it stops answers being drawn from content that was withdrawn. ### What it doesn't fix I wouldn't call this a cost control in the sense of a plan or price change. It doesn't alter Qdrant's per-cluster pricing, the memory a given vector count requires, or the replication factor you choose.  If the collection is too large for its node, a tidier sync only slows the growth. Size the workload first; then use the workflow to keep it from growing beyond what you sized. ## A Monday checklist for sizing your Qdrant plan Work through these seven steps in order, because each one's output is the next one's input: 1. Count vectors and dimensions. 2. Test quantization on recall. 3. Run the pricing calculator. 4. Set a budget alert. 5. Decide replication. 6. Set a free-versus-paid review date. 7. Re-check the pricing page. ### Measure the workload Count every vector you'll store, including the ones you plan to add this quarter, and note the dimensions of your embedding model. Memory is the product of those two counts, so a guess here carries into every later line of the bill. Then run your own queries against a quantized copy of the collection and compare recall with the unquantized original. Quantization shrinks memory, but only your data can tell you whether the lost accuracy is acceptable. ### Price it three ways Run the pricing calculator with the full-precision size, the quantized size, and the quantized size with replication. Three results side by side show how much of the bill comes from each decision rather than from the plan name. Set a budget alert before launch. An alert at the planned spend turns a surprise on the invoice into a message you can act on within the month. For replication, ask the auditor's question: if one node or zone fails, what do users see? Replicas are what keep search answering, and they multiply the memory you are paying for. Decide the level deliberately and write down the failure it is meant to survive.  ### Set a review date for your Qdrant plan Put a date in the calendar to revisit the free-versus-paid choice, ahead of the point where your vector count would outgrow the free tier. A date you chose in advance beats discovering the limit through a failed write. On that date, re-check the pricing page itself. Plans and limits change, and your spreadsheet only reflects the page as it was when you last read it. ## Frequently asked questions These're the points the body leaves open, and each answer carries the same caveat: confirm it against the live pricing page before it goes into a budget. ### Cost of using Qdrant Is Qdrant free to use? Yes, in two separate ways, and neither covers a production workload by default. The open-source software costs nothing to license, and Qdrant Cloud offers a free cluster with tight resource limits. The first moves the cost to your own infrastructure and staff. The second suits prototypes, so a workload that outgrows it is the point where a bill appears. Does Qdrant Cloud charge per query or per vector? Neither. Cloud pricing follows the resources a cluster reserves, such as memory, CPU and disk, and not the number of queries or stored vectors. Vector count still matters, but only because it determines how much memory the cluster needs. An idle cluster costs the same as a busy one, so over-provisioning's the expense to watch. ### Moving and hosting choices Can I move from free to a paid cluster without re-uploading? Qdrant documents an upgrade path from the free cluster, so a full re-upload shouldn't be necessary. Treat that as a claim to test, not a guarantee. Take a snapshot of your collections before the change, and check that the collection settings and replication you expect survived it. Is self-hosting Qdrant cheaper than Qdrant Cloud? Only if you count everything. Self-hosting removes the cluster fee but adds servers, backups, upgrades, monitoring and on-call time. Hybrid Cloud, which runs the database on your own Kubernetes infrastructure under Qdrant's management layer, doesn't remove the compute bill. You still pay for the machines, so it changes who operates the cluster, not whether you pay for memory. ### Pricing changes How often does Qdrant change its pricing? **There's no fixed schedule that I can cite**, so assume it can change at any time. Plans, free-tier limits and resource options have all been adjusted by vendors in this market without much notice. Record the date you last read the page, and recheck before renewing or resizing. ## Related reading - [Bubble.io Pricing in 2026: Plans and Real Costs](https://www.activepieces.com/blog/bubbleio-pricing-in-2026-plans-and-real-costs) - [Lovable Pricing 2026: Plans, Credits & Real Costs](https://www.activepieces.com/blog/lovable-pricing-2026-plans-credits-real-costs) - [DigitalOcean Pricing: Plans and Real Costs in 2026](https://www.activepieces.com/blog/digitalocean-pricing-plans-and-real-costs-in-2026) ## References - [SpendArk instance directory](https://spendark.com/instances/) - [Spendark](https://spendark.com/blog/cloud-tax-price-comparison-2026/) - [VePrompts RAG architecture calculator](https://veprompts.com/tools/rag-architecture-calculator/vector-db/qdrant/)If the managed service goes down, that's Qdrant's incident; if your own node goes down, it's yours. Ask which of those you are actually buying.