Most “build a RAG pipeline in n8n” tutorials end at the point where it returns an answer. That is roughly a third of the work, and the missing two thirds is capacity: how much RAM this stack needs, which of the four moving parts drives that number, and at what point it stops fitting on one server.

This post is the sizing. The numbers come from Qdrant’s own published capacity planning rather than from anyone’s guess, including ours.

How much RAM does Qdrant need for RAG?

Qdrant publishes a formula, not a number. For 2 million points at 768 dimensions in float32 it comes to about 6.11 GB: 5.72 GB for the dense vectors, 0.29 GB for the HNSW index, 0.10 GB for the ID tracker, plus roughly 20% headroom on top. Quantization changes it dramatically: under 4-bit TurboQuant the dense vectors drop to about 0.72 GB, which brings the total to roughly 1.1 GB - the HNSW index and the ID tracker do not shrink.

The formula, so you can size your own

Qdrant’s capacity planning docs give three components. Their worked example is 2,000,000 points at 768 dimensions:

Dense vectors - points × dimensions × bytes_per_dim

PrecisionBytes/dim2M × 768
float32 (default)45.72 GB
float1622.86 GB
uint811.43 GB
4-bit TurboQuant0.50.72 GB

HNSW index - points × m × 2 × 4 bytes × 1.2 → with m=16, about 0.29 GB

ID tracker - points × 52 bytes → about 0.10 GB. This one is always resident in RAM, no matter what you do to the vectors.

Total for the float32 case: 5.72 + 0.29 + 0.10 ≈ 6.11 GB, and Qdrant’s own instruction is to “add ~20% headroom on top of your final RAM and disk totals.” So call it 7.3 GB in practice.

The quantization lever is the whole game. Qdrant’s own words on the aggressive end: “with 4-bit TurboQuant (8x compression, 0.5 bytes per dimension), originals moved to cold, and quantized vectors pinned, RAM for dense vectors drops from 5.72 GB to […] ≈ 0.72 GB.”

That is a 2 GB server versus an 8 GB one for the same corpus. Before you buy a bigger box, check whether you turned quantization on. Most people building their first RAG pipeline have not, because the tutorial did not mention it.

Scaled down to the sizes people actually start at, float32 at 768 dimensions:

VectorsDense+ HNSW + IDs+20%
50,0000.14 GB0.15 GB0.18 GB
250,0000.72 GB0.76 GB0.92 GB
1,000,0002.86 GB3.05 GB3.66 GB
2,000,0005.72 GB6.11 GB7.3 GB

Under about 250,000 vectors this is not the thing that decides your server. Past a million it is the only thing.

The four parts, and which one actually costs

An n8n RAG stack is usually four pieces, and they have wildly different appetites:

PartWhat it needs
n8n~180 MiB baseline, more for agent loops
QdrantPer the formula above - scales with your corpus
PostgreSQLSmall. Metadata and n8n’s own data
The modelEither ~nothing, or everything

That last row is the fork in the road and it is worth deciding before anything else.

Hosted model API - Anthropic, OpenAI, Gemini, or anything through OpenRouter. Inference costs nothing in RAM and bills per token. Your server sizing is then just n8n plus Qdrant, and the tables above are the whole answer.

Ollama, locally - inference moves onto your hardware. This is a different class of machine: tens of gigabytes and realistically a GPU. It is not a variation on the numbers above, it replaces them.

Neither is wrong. But a great deal of RAG content quietly assumes the second while quoting costs that only make sense for the first.

The n8n self-hosted AI starter kit, and its one gap

n8n-io/self-hosted-ai-starter-kit is Apache-2.0, 15,222 stars, last pushed 23 July 2026. It bundles self-hosted n8n, Ollama, Qdrant and PostgreSQL in one Docker Compose, and pulls Llama 3.2 by default.

It is a good way to see the shape of the stack. Two things to know before you build on it.

n8n’s own framing, verbatim from the docs: “n8n designed this kit to help you get started with self-hosted AI workflows. While it’s not fully optimized for production environments, it combines robust components that work well together for proof-of-concept projects.”

It publishes no hardware requirements. Not on the docs page, not in the README. If you have seen a specific RAM figure quoted for the starter kit, someone made it up. What the README does document is GPU profiles: --profile gpu-nvidia, --profile gpu-amd on Linux, --profile cpu, and a note that Mac M-series users cannot expose the GPU to Docker and should run Ollama natively on the host with OLLAMA_HOST=host.docker.internal:11434.

The nearest published n8n number is the AI Assistant requirement of 4 GB RAM and 2 vCPU - and note that is for n8n’s AI Assistant sandbox specifically, not for n8n itself, which has no published minimum. n8n server requirements sorts out which circulating number is which. Either way it does not account for Ollama loading a model.

Qdrant self-hosted vs Qdrant Cloud

Qdrant is Apache-2.0, 34,339 stars, so there is no licence cost either way. What you are choosing is who runs it.

Qdrant Cloud free tier, from their pricing page: “Single Node Cluster. 0.5 vCPU / 1GB RAM / 4 GB Disk.” Free forever, for testing and prototypes.

That 1 GB, read against the table above, is roughly 200,000-270,000 float32 vectors at 768 dimensions once you apply Qdrant’s own 20% headroom rule, or several million quantized. For a prototype that is plenty. For a document corpus of any size it is not.

Paid Standard tier is usage-based, and Qdrant publishes no dollar figure. No monthly price appears anywhere on their pricing page - it is a calculator. Their own description: “Billing is calculated based on actual resource usage during the billing period. You’re charged for compute (vCPU), memory (GB), storage (GB) consumed by your clusters, storage (GB) consumed by backups, and used inference tokens of paid models. Usage is billed hourly.”

We are not going to invent a number for it, and you should distrust any comparison page that quotes one.

The honest trade: Cloud is metered and elastic, self-hosting is a flat server cost you can compute in advance from the formula above. Which is better depends entirely on whether your corpus is stable. A fixed document set is the easy case for self-hosting, because the number never surprises you.

Putting it on real servers

Working from the tables, for a hosted-model setup (n8n + Qdrant + Postgres, inference over an API):

These are vector-store numbers on top of n8n’s own footprint. For n8n’s side of the sizing, see n8n server requirements.

Prototype, under ~250k vectors, quantized. n8n’s ~180 MiB baseline, Qdrant well under a gigabyte, Postgres small. Fits on 2 GB. On InstaPods that is the Build plan at $7/mo - 2 vCPU, 2 GB RAM, 25 GB SSD - with a managed PostgreSQL on the same pod. That is also the smallest plan we run n8n on at all, for the memory reasons in the agent post.

Up to ~1M vectors, float32. Qdrant alone wants ~3.66 GB with headroom, and n8n, Postgres and the OS still have to fit beside it - so the Grow plan at $15/mo (2 vCPU, 4 GB, 50 GB) does not actually hold this configuration. Either quantize, which drops it under a gigabyte and fits Grow comfortably, or give Qdrant its own pod. Quantizing is the cheaper of the two.

2M+ vectors, float32. ~7.3 GB for Qdrant alone. Scale, $25/mo (4 vCPU, 8 GB, 100 GB), and at this size Qdrant wants its own machine rather than sharing with n8n’s agent loops, because the two spike independently and the one that loses is whichever asked for memory second.

Local models via Ollama. None of the above. You want a GPU box, which is not something we sell and not something most VPS providers sell cheaply either.

The genuinely useful advice, which costs us money to give: quantize before you upgrade. Going from float32 to 4-bit on a 2M-vector collection is 8x on the dense vectors and about 5.6x on the total once the HNSW index and ID tracker are counted - 7.3 GB down to 1.3 GB. That is two plan tiers, Scale back to Build. It costs you some recall precision and a config change. Buying an 8 GB server to hold vectors you could have held in under 2 GB is the most common avoidable cost in this stack.

What hosting does not solve

Retrieval quality. Chunk size, embedding model, overlap, whether you rerank, and whether your source documents are any good - those decide whether the answers are useful, and no amount of RAM affects them. Server sizing decides whether the thing stays up. They are unrelated problems and only one of them is ours.