What a knowledge graph costs

Short answer

The software and the machines are usually the small part. A graph database can run for free or for a modest monthly fee, and the language-model calls that help build a graph often cost less than people expect. The real cost is people's time: deciding which questions the graph must answer, modelling the domain, working out which records describe the same thing, checking that answers are right, and keeping the data current after launch. Budget for that first. The one machine cost that grows is the model calls behind every question someone asks. In a pilot with a handful of users it is negligible. In production, with many people asking every day, it can become the largest running cost, so model it before you roll out, not after.

Where the money goes

Phase	What you pay for	What drives it
Build	Scoping, ontology, control questions	Hours from a builder and a domain expert
Build	Loading structured sources	Engineering time, then almost nothing per run
Build	Extracting facts from text with an LLM	Volume of text, choice of model, number of re-runs
Build	Entity resolution and review	Domain expert time, usually the largest line
Run	Graph database	Memory and uptime requirements
Run	Questions in a chat or agent	Model calls per question, times number of questions
Maintain	Refreshes, schema changes, new tests	Hours every time a source or a question changes

One pattern runs through the table. The rows billed by the token are cheap and easy to measure. The rows billed by the hour are expensive and easy to leave out of the budget.

What makes a graph cheap or expensive

Where the data comes from. This matters more than anything else. Registers, databases, spreadsheets, APIs and machine-readable filings can be loaded with parsers: exact, repeatable, and nearly free to re-run. Facts buried in prose, PDFs and emails need a model to extract them, a check that the model didn't invent anything, and a person to review what's left. Two graphs of the same size can differ in cost by an order of magnitude purely because of this.

How many kinds of things must be matched. Every entity type that appears under different names in different sources (companies, products, substances, people) is a resolution problem. Someone has to decide when two names are the same thing and be able to defend that decision. The more types, and the messier the names, the more expert hours.

How right the answers must be. A graph that suggests leads can tolerate mistakes. A graph that supports regulated decisions cannot. Higher stakes mean more review, more tests and full provenance on every fact, and each of those is work.

How fresh the data must stay. A graph built once from a fixed archive is a project. A graph fed by sources that change every week is a small ongoing operation, and it needs an owner.

How many people ask questions. The database barely notices more users. The model calls behind a chat interface are paid per question, so usage drives the running bill, and it is the one cost that keeps growing after the build is done.

Graph size, surprisingly, is rarely the main driver. Hundreds of thousands of nodes loaded from a clean register can cost less to build than a few hundred extracted carefully from prose.

The costs people forget

Re-running the extraction. The first pass is never the last. Every change to the prompt or the schema can mean paying for extraction again, across every document. Cache every model call and keep intermediate results on disk, so a rebuild only pays for what changed.

Sources that change under you. Public and internal data change on their own schedule: files get renamed, columns move, code lists are revised, one source updates before another it depends on. None of it is expensive once, but someone has to notice. A graph nobody refreshes becomes wrong quietly.

Tests that grow with the graph. Each bug you find usually becomes a new check, and each new layer of data adds assumptions to protect. A test suite that stops growing usually means nobody is looking anymore. The guide on how to test a knowledge graph covers what to check.

The limits of free and cheap hosting. Free tiers of managed graph databases cap the number of nodes and relationships, and a real domain can pass those caps sooner than you'd think. Self-hosted community editions are free but leave backups, availability and upgrades to you, and some limit how many separate databases one instance can hold. Paid managed services are priced mostly by memory. Check the limits against your estimated size before you commit, not halfway through.

The bill that arrives with users. A single question in a chat interface can mean several model calls: understanding the question, finding the starting point in the graph, writing a query, sometimes fixing it, and writing the answer. During a pilot this barely registers: a few testers asking a few dozen questions a day cost less than the time spent reading the answers. In production the same per-question cost is multiplied by every user, every working day, and it scales in a straight line with adoption. A cost nobody noticed in the pilot can become the biggest line in the running budget.

The levers are known, and they are cheaper to build in early than to retrofit:

• Use the large model only where it earns its price. Routing, extracting names from the question and writing the query can often run on a small model. The large one is for writing the final answer, or only for hard questions.
• Keep the prompt small. Send the model the rows the query returned, not a large slice of the graph. How much context goes into each answer affects the bill more than the size of the graph.
• Reuse answers. Many questions repeat. Caching answers, or the queries behind them, turns a repeated question into a free one.
• Not every question needs a model. Common questions can become fixed queries, reports or dashboards that run on the graph alone.
• Measure and cap. Log cost per question from the first day, and set per-user and daily limits before the first user arrives.

How to estimate yours

1. Sort your sources into structured and prose. For each one, check whether an export or an API exists before planning to extract from documents. Every source that moves to a parser cuts both cost and error.
2. Price extraction on a sample. Run the model on a small share of the text, measure the tokens, and multiply up. Then multiply again by the number of full re-runs you expect while the model settles.
3. Count the entity types that need resolving. Each one is a review job for someone who knows the domain. This estimate matters more than the token estimate.
4. Estimate the graph's size before choosing hosting. Rough node and relationship counts from your sources are enough. If you are near a free tier's limit, plan as if you are over it.
5. Price one answer, then price a year of them. Count the model calls per question and measure the cost of one answer during the pilot. Multiply by users, questions per user per day and working days at full rollout. That number, not the pilot bill, belongs in the production budget. Set a hard spend limit with your model provider either way.
6. Name an owner for each source. Write down how often it changes and who notices when a file arrives late, half empty or in a new format.

If steps 3 and 6 come out larger than you can staff, the project is too big for a first pilot. Narrow the scope until they fit.

Example from a working graph

The two graphs behind this site show the pattern. The plant-protection register graph is large, but almost all of it comes from structured government data, so the model calls in its build cost well under a dollar. The 10-K filings graph is small, but its most useful layer (who competes with whom, who depends on whom) exists only in prose, so the model had to read it, and even then the extraction cost a few dollars. In both cases the API bill was the smallest number in the project. The time went into matching names that refer to the same company or pest, writing the checks that catch bad extractions, and building the parts around the model.