Qdrant Cloud Pricing Explained (2026)

The Founder Who Priced a Vector Database Before Writing a Line of Code

A few months back, a founder I know sent me a screenshot of the Qdrant Cloud pricing page with the caption “is this going to bankrupt me?” He was building a support tool — the usual thing, “let users ask questions against our help docs” — and somewhere in a weekend of reading threads he’d decided the serious way to do it was a dedicated vector database. So he opened the pricing page, saw compute and memory and disk billed by the hour, and panicked before he’d embedded a single document.

I know that panic intimately. It’s the exact same disease that made me spend three weeks benchmarking databases for a URL shortener with zero users. So let me do for you what I wish someone had done for me: explain what Qdrant Cloud actually costs, why it’s priced the way it is, and then talk you out of using it — at least for now.

Because here’s the punchline up front. Qdrant is a genuinely excellent piece of software. And for most founders adding one AI feature, it’s the wrong first tool. The right first tool is the Postgres database you’re already paying for.

---

What a Vector Database Even Does

Skip this if you already know, but most people searching “Qdrant Cloud pricing” don’t — they’ve just been told they need one.

When you build “chat with my docs,” the model doesn’t magically know your content. So you chop your documents into chunks, and turn each chunk into an embedding — a long list of numbers that captures its meaning. “How do I reset my password” and “I forgot my login” end up as numbers that sit close together, even though they share no words. When a question comes in, you turn it into numbers too, and go find the chunks whose numbers are nearest. Those are your relevant paragraphs. You paste them into the prompt and let the model answer. That’s RAG — retrieval-augmented generation, and I untangled it from its cousin in MCP vs RAG if the acronyms are still fuzzy.

A vector database is the thing that stores those number-lists and finds the nearest ones fast. That’s the whole job. Qdrant is one of the best at it: open-source, written in Rust for speed, run out of Berlin, and well-funded — it raised a $28M Series A in early 2024 and a $50M Series B in March 2026, so it isn’t going anywhere. Being a European company, GDPR compliance comes baked in, which is one less thing to sweat.

The thing to hold onto is how it finds the nearest vectors quickly: it keeps them in RAM. And that one fact explains the entire pricing page.

---

How Qdrant Cloud Pricing Actually Works

Qdrant Cloud isn’t priced like Pinecone’s older per-query model, where you pay per read. It’s priced like renting a server. You allocate a cluster with a certain amount of vCPU, RAM, and disk, and you pay for that allocation by the hour — whether you run 100 queries a day or five million. Compute, memory, storage, backup storage, and any inference tokens from their paid models all meter separately, and you get one invoice a month for the prior month’s usage.

There are four tiers:

• Free. A single-node cluster with 0.5 vCPU, 1GB of RAM, and 4GB of disk. Free forever, no credit card. The catch worth knowing: leave it untouched and it gets suspended after a week of inactivity, then deleted after four. Fine for prototyping, not for a side project you’ll ignore for a month.
• Standard. Usage-based billing on dedicated resources, with vertical and horizontal scaling, backups, and a 99.5% uptime SLA. This is where real workloads live.
• Premium. Adds a 99.9% SLA, SSO, and private VPC links — with a minimum spend. This is enterprise-shaped.
• Hybrid / Private Cloud. Run Qdrant on your own infrastructure while they manage the control plane. Pricing is “contact sales,” which is code for “you’ll know if you need it.”

Qdrant doesn’t publish a flat per-GB rate, which is honest of them — your bill depends on the exact machine you spin up. But the third-party calculators land in a consistent ballpark: a small production cluster (a couple of GB of RAM) runs roughly $30–60/month, a standard production setup lands somewhere around $80–160/month, and a beefier 8GB cluster climbs past $120/month and keeps going. Treat those as directional, not gospel — but the shape is clear.

And that shape has one dominant term: RAM.

---

The RAM Trap Nobody Warns You About

Here’s the part that bites founders. Your vectors live in memory, so your bill is really a function of how many vectors you have and how big each one is.

Rough math from Qdrant’s own sizing guidance: for typical 1536-dimension embeddings with some metadata, budget around 100,000–120,000 vectors per GB of RAM in production. So the free 1GB tier holds maybe a hundred thousand chunks. Sounds like a lot until you realize a single 300-page PDF chopped into chunks can be a few thousand vectors, and a real document library is millions.

Do the arithmetic and it gets uncomfortable fast. A million vectors wants ~10GB of RAM. Ten million wants ~100GB. And RAM is the expensive resource on any cloud — this is the same reason I’ve watched people’s bills explode elsewhere. Qdrant gives you escape hatches (quantization can shrink memory use dramatically, and you can push some data to disk), but now you’re tuning a database instead of shipping your feature. That’s the trap: you didn’t sign up to become a vector-DB operator, but the pricing model quietly turns you into one.

None of this is a knock on Qdrant. It’s the honest cost of a dedicated, in-memory vector engine. The question is whether you need that engine yet. For most of you reading this, the answer is no.

---

The Broken Engineer Verdict: pgvector on Neon First

Here’s what I’d actually do, and what I tell every founder who sends me that panicked pricing screenshot.

If you’re already running Postgres — and if you’ve read the survival guide, you know I keep seven databases on Neon’s free tier — then you already have a vector database. You just haven’t turned it on. pgvector is an extension that adds a vector column type and similarity search to the Postgres you’re already paying for (which, on Neon’s free tier, is nothing). Your embeddings live one table over from your users. No new service. No new dashboard. No new bill. No cluster to suspend or resize or quantize.

The whole pipeline for “chat with my docs” becomes embarrassingly small:

1. An embeddings call to OpenAI or Anthropic to turn each chunk into numbers.
2. INSERT those numbers into a vector column in Postgres.
3. At query time, one SELECT ... ORDER BY embedding <-> $query LIMIT 5, stuff the results into your prompt, call the model.

That’s it. Forty lines, give or take. I made this exact argument in more depth in LlamaIndex vs LangChain — the honest answer for most AI features isn’t a fancy framework or a dedicated database, it’s an embeddings call and a WHERE clause. And it’s the same discipline I preach about not orchestrating a two-service app on Kubernetes: write the boring direct version first, ship it, live with it.

Will pgvector win a benchmark against Qdrant at fifty million vectors? No. It’s not trying to. But you don’t have fifty million vectors. You have a help center, maybe a few thousand chunks, and a feature you want to ship this weekend. pgvector handles that without you thinking about RAM once. (If you want the deeper tour of Postgres and every database I over-engineered around it, that’s the advanced database guide.)

A dedicated vector database is a bet that retrieval scale is your problem. For a founder shipping one AI feature, it almost never is — yet.

---

When Qdrant Actually Earns Its Money

I’m not here to tell you Qdrant is useless — that’s lazy contrarianism, and there’s a real line where it flips from over-engineering to the obviously correct tool. You’ve crossed it when retrieval is genuinely the product, not a side feature bolted onto a SaaS.

Concretely, reach for a dedicated vector DB like Qdrant (or a managed one like Pinecone, or the dead-simple Chroma if you want free-to-start) when:

• You have millions of vectors, not thousands. A real, growing corpus — a search product, a large internal knowledge base, embeddings over your entire user-generated content. This is where Postgres’s vector indexing starts to strain and a purpose-built engine pulls ahead.
• Latency is a feature you’re selling. When “instant, relevant results at scale” is the pitch, Qdrant’s in-memory Rust core, filtering, and quantization are deep tools that a Postgres extension won’t match.
• You need the vector-DB-specific machinery — advanced payload filtering, hybrid search tuned hard, billion-scale sharding. If you’re using those words in earnest, you already know you’ve outgrown pgvector.

The tell isn’t “I might scale someday.” Every founder feels that. The tell is a bill and a latency number you can measure and hate. When you hit it, Qdrant will be sitting right there, and its free 1GB tier is a perfectly nice place to prototype the migration. Pay the tax then — you’ll be getting real value for it.

---

The Bottom Line

Qdrant Cloud pricing isn’t scary once you see the shape of it: a free 1GB cluster to play with, then usage-based billing on the vCPU, RAM, and disk you allocate — with RAM doing most of the damage, because that’s where your vectors live. A small production cluster is $30–60/month, and it climbs from there as your vectors multiply. That’s a fair price for a genuinely great, open-source, Rust-built vector engine.

But “fair price for a great tool” and “the tool you need this week” are different questions, and the internet only ever answers the first. For the founder who sent me that screenshot, the answer was pgvector on the Neon database he was already running for free. He shipped his support bot that weekend, paid $0 extra, and never opened the Qdrant pricing page again — until, maybe, the happy day his corpus grows into a real library. Not a day sooner.

Match the tool to the problem you actually have. A help center is not fifty million vectors. Embed the docs, add a vector column, ship the thing.

This is the Broken Engineer Guide — I over-engineer everything, fail at business, and hand you the shortcuts so you don’t have to bleed for them. Start with the database you already pay for.