What a RAG System Actually Costs: Numbers From a Production Build
Every time someone asks me what a RAG system costs to build, I give the same answer and watch them visibly deflate. It’s pretty simple: not much, if you know what you're doing. And a lot, if you don't.
I know, this is not a satisfying answer. People who ask the cost question want a number. Something that they can easily fit into a budget line. Something they can take back to their CFO and defend. So in this post I'm going to give you actual numbers from a real build, a retrieval-augmented chatbot for a regulated Canadian ecommerce company I worked on in 2025, and then I'm going to explain why those numbers are misleading if you read them the wrong way.
The numbers from the build
The use case was customer support. The company was running roughly 20 HelpScout tickets per day, most of them repetitive: order status, product availability, shipping questions, the same regulatory questions every customer in that category asks. The team was spending hours on tickets that had the same five answers behind them. The goal was to deflect the repetitive ones so the human agents could focus on the cases that actually needed a person.
After the build, the chatbot was handling 18 to 19 of those tickets per day. One or two per day still needed a human. That's a >90% deflection rate on a problem the business had been paying salaried staff to solve.
Here's what it cost to run, per month:
| Component | Monthly cost | |---|---| | n8n on a Vultr shared instance | ~$6 | | Supabase (vector store + Postgres) | $0 (free tier) | | Claude API (answer generation) | ~$5 monthly | | OpenAI API (embeddings) | ~$5 monthly | | HelpScout integration | $0 (existing account) | | Total monthly infra + API | $16 |
The build cost was a fixed-price consulting engagement. I'm not going to publish that number here because it varies by scope and by client, and putting a single figure on a public page would mislead more people than it would help. If you want the range, the discovery call is where we talk about that.
So the running cost is somewhere in the low double-digits per month against a deflection rate that was saving the company multiple hours of human agent time per day. The unit economics worked out roughly the day we turned it on.
Why the number is misleading
Reading the table above, you might conclude that RAG is essentially free. A shared instance on Vultr, a free Supabase tier, some API calls, done. If you've ever priced enterprise software, those numbers look like a typo.
They aren't. But the table is hiding three things.
- The infrastructure cost is low because the design absorbed the complexity. Running n8n on the cheapest Vultr tier is fine when you've planned for the instance to fail and built the system so a failure doesn't cost you customer data. It's a disaster when you haven't. The "savings" of running on a $6 box vs. a $60 box only exist if your architecture can tolerate the failure modes of the $6 box. Most people skip that part and get a bill for the consequences later.
- The API costs are low because the retrieval is good. The most expensive thing you can do with an LLM is ask it a question without giving it the right context. The model fills in the gap with tokens, and you pay for tokens. Good retrieval means you send fewer tokens, get better answers, and pay less. Bad retrieval means you pay more for worse answers. The difference between a $50/month API bill and a $500/month API bill on the same volume is almost always the quality of what you're retrieving.
- The free tier of Supabase was enough because the corpus was small and well-curated. A few hundred well-written knowledge base articles, product descriptions cleaned up, and regulatory copy reviewed by the client's compliance person. Embedded once, updated rarely. If you point a RAG system at five years of unorganized Confluence pages, you'll outgrow the free tier of any vector store on the first weekend, and you'll get worse answers besides. The cost of running the system tracks the quality of the corpus you point it at.
So the real cost equation looks like this:
Total cost = infrastructure + API usage + (work to make those two not matter)
Where the money actually goes in a RAG build
- Corpus preparation. The single biggest cost on most builds, and the one people most consistently underestimate. Your existing documentation is almost certainly not in a state where an embedding model can do useful work with it. Pages contradict each other. Old policies live next to new ones. Internal jargon doesn't map to what customers actually ask. Someone has to read through it, decide what's authoritative, rewrite the ambiguous parts, and split or merge documents until the chunks an embedding model produces are actually retrievable. On the Canadian build, this was weeks of work with the client's content lead. It's editorial work, and it's the part that determines whether the rest of the system is worth building.
- Retrieval design. What gets retrieved when? How many chunks? How they're re-ranked. Whether you use hybrid search (vector + keyword), whether you filter by metadata, whether you have separate indexes for different document types. These decisions look small in isolation. They compound into the difference between a system that answers 90% of queries correctly and one that answers 60% and confidently hallucinates the rest. Most of the engineering value in a RAG build lives here.
- Prompt design and guardrails. What the model is told to do with what it retrieves. How it handles questions it can't answer. How it cites sources. How it refuses to answer things outside its scope. For the regulated e-commerce client, this took serious time. There were specific questions where the answer had to include a disclaimer or redirect to a human agent. Building those rules into the prompt and verifying them across hundreds of test cases is real work.
- Evaluation infrastructure. How do you know the system is working? Not "looks fine in the demo." Actual measurement against a held-out test set, with regression tests when you change the prompt or swap the model. Without this, you have no way to tell whether your last change made things better or worse. You also have no defensible answer when the client asks why the system gave a bad answer to a specific question.
- Maintenance and drift. A RAG system is not a project. It's an asset that needs to be fed. New products, new policies, new regulations. Old answers go stale. The system needs someone who watches the metrics, updates the corpus, retests the prompt, and catches when the retrieval starts pulling the wrong things because the corpus has shifted under it. This is the cost nobody includes in their initial budget and that everyone discovers six months in.
Rough numbers for a build like this
A discovery engagement to figure out whether RAG is even the right answer for your problem: low four figures, paid, usually one to two weeks. Sometimes the answer is "no, you don't need RAG, you need a better FAQ page and three workflow fixes" and that's a result the client should be happy to pay for.
A full build for a use case like the Canadian ecommerce one: low to mid five figures depending on complexity, integrations, and how much corpus work the client can do internally vs. how much I do.
Ongoing maintenance: typically a fractional engagement, anywhere from a few hours a month to a few days, depending on how much the corpus changes and how high the stakes are.
Infrastructure and API costs, once the system is built: usually one to two orders of magnitude smaller than the build cost. Most clients are surprised by this. They expected the running cost to dominate. It doesn't, unless you skip the design work that makes the running cost stay small.
When RAG is the wrong answer
If your use case can be solved with a good search bar and a well-written FAQ, RAG is overkill. If your corpus is small and stable enough that fine-tuning would work better, RAG is the wrong tool.
The clients I've seen get the most value from RAG share three things: a high-volume, repetitive query problem; a knowledge base that's worth investing in regardless; and a team that's serious about maintenance after the build. If two of those three are missing, the math doesn't work no matter how cheap the infrastructure is.
What the cost question is really asking
When someone asks what RAG costs, what they usually mean is "how do I know if this is worth doing?" The infrastructure number is the easy half. The hard half is whether the use case justifies the corpus work, the retrieval design, the evaluation infrastructure, and the maintenance commitment.
The Canadian e-commerce build paid for itself in months. The maintenance is ongoing and modest. Total cost over a year, including the build, was a fraction of what a single additional support hire would have cost over the same period, and the system scales without proportional cost increases.
But it worked because the use case was right. The corpus was buildable. The team committed to maintenance. The number at the bottom of the invoice was the result of those decisions, not the input to them.
If you're trying to figure out whether RAG is the right answer for your problem and what it would actually cost in your specific situation, that's what a paid discovery call is for. You get a written scope, a defensible budget, and an honest answer about whether to build it at all.
What's your support volume looking like this quarter?