Cost & materialization

The ontology was good work. The entities were named the way the business really talks. The keys held. The relationships were bound to the columns they claimed. It validated clean, it published, and the graph came up on the first try. The answers were good too: exact, easy to trace, and walked over real edges.

Then the month closed, the capacity bill came in, and nobody could explain it. Nothing had broken. No runaway job. No infinite loop. No notebook left running over a weekend by mistake. Someone finally counted how many questions the graph had been asked in thirty days. Nine.

The graph had done nothing wrong. It had done one thing all month: exist. And that points to the belief nobody says out loud, because it feels too obvious to say: the graph is free until someone asks it something.

That is true of a view. A view is a saved question. It is a small piece of text the engine keeps until you call it, and a question nobody asks costs nothing. A graph is not a saved question. It is a built thing. It got built, and then it sat there. It took up room, and it stayed warm enough to answer. It billed for both.

A view is a question. A graph is a thing.

A view holds no rows. It is a sentence the engine remembers: when someone asks for this, run that. Between asks it is a few hundred bytes of text in a catalog, doing nothing and costing nothing. Ask it a hundred times and you pay a hundred times. Ask it never and you pay never. The meter and the question are the same event.

A materialized graph broke that link the moment it got built. The nodes and edges are real. They are resolved and stored somewhere, and that somewhere has a size that must be provisioned. To answer, something also has to be awake: an engine, warm, holding the graph, ready to walk it. Neither of those is a question. Both of them are a bill.

Look at what is different between the two panels. It is not the spikes. Three questions, three spikes, and they are about the same on each side. The difference is the band along the bottom of the right panel that never goes away. That band is the cost of having built the thing, and not asking never makes it smaller.

What precomputing buys you, and what it costs

This is not a graph problem. It is one of the oldest trade-offs in data engineering, and you have made it many times without naming it.

Any time you precompute, you move work from the moment of the question to the moment before it. A cache, an index, a materialized view, an aggregate table, a knowledge graph: it is the same bet every time. Pay once, up front, to make each later question cheap. The bet pays off when there are enough later questions to spread that up-front cost across them.

The lines cross. That single point is the whole story. Left of it, you have bought a fast answer to a question nobody asked often enough to be worth the speed. Right of it, you are winning, and the more you ask, the more you win.

Nobody in the story did anything wrong, and that is the hard part. They built a graph that would be great at question number four thousand, and then asked it nine. They were deep inside that shaded triangle, and being inside the triangle looks exactly like a bill that makes no sense.

The shape of your asking, not just the amount

There is a second catch, and it traps careful people, because it stays a problem even after you have plenty of questions.

Uptime is not billed in the units you use it in. It is billed in the units the meter counts in, and meters round up. A session that runs for nine seconds and a session that runs for fifty-nine seconds can cost exactly the same, because both round up to one minute. So two teams doing the same total work can get very different bills, only from the shape of their asking. Spread it out over twenty small sessions and you buy twenty minutes. Put it into one session and you buy four.

Set the shape yourself and watch the two numbers move apart.

Push the session length down and the penalty gets worse, not better. That is the opposite of what you would expect. Shorter sessions feel cheaper. They are not, because you are not buying seconds. You are buying minutes, and a ten-second session buys fifty seconds of nothing. Now drag the storage slider down. Take the graph to almost nothing and watch the billed number simply stop. There is a floor under it, and you were standing on that floor long before your data ever reached it.

What the meters actually count

Fabric IQ hides none of this, and the numbers are exact enough to plan against. All of them below are as of 15 July 2026.

Graph operations are billed based on CPU uptime. Each second of uptime costs 10 CU-seconds, and each session of CPU uptime is rounded up to minutes. That is the rounding you just played with, at the real rate. The docs are careful about what counts: graph operations, including data ingestion, querying, and running algorithms. Notice that ingestion is on that list. Building the graph is metered too, not just asking it questions. ("Materialization" is our word for the whole build-and-sit act. It helps for teaching, and it is not a term you will find in the product docs, so do not go looking for it there.)

Storage is the floor, and the floor has a number. For graph storage the system provisions a minimum of 100 GB, billed at the same rate as OneLake Cache. A near-empty graph and a 90 GB graph cost the same to store, because both are standing on the same floor.

So there are two meters for the graph itself. Graph general operations bills to graph capacity usage CU. Graph cache storage bills to OneLake Cache. You do not buy anything special to get either one. There is no separate graph license or SKU, which is exactly why it can surprise you. It lands on the Fabric capacity you already have. Nobody signed a new contract for it, so nobody was watching for it.

The one good thing is that it puts itself to sleep. The graph shuts down on its own when it is not in use, so idle time is not uptime. The floor is storage, not compute. This is also why the shape of your asking matters so much here: an engine that wakes, answers for eight seconds, and goes back to sleep, twenty times a day, is twenty sessions, twenty roundings, and twenty billed minutes.

Above the graph, the ontology item has meters of its own. Ontology Modeling runs at 0.0039 CU per hour. Ontology AI runs at 400 CU-seconds per 1K input tokens and 1,600 per 1K output. There is a third, Ontology Logic and Operations, listed at 0.666667 CU per minute, and it is not currently in effect. Read that one slowly, because people misread it as a discount. It does not mean the logic runs free. It means ontology users are only billed for logic and operations according to their underlying Fabric Graph usage. The meter above is switched off. The meter underneath is very much on.

This kills the belief that does the most quiet damage: that preview means unbilled. Being in preview stops nothing about graph billing.

And be exact about what is in preview, because it is a split and not one blanket status. The graph engine underneath is generally available as of July 2026. The ontology item sitting on top of it is still in preview. So "it is only preview, we will worry about cost at GA" is wrong twice over: the thing doing the billing already went GA, and the preview thing bills through it anyway.

One last habit. Every rate on this page is stamped 15 July 2026, and Microsoft says plainly that these rates are subject to change at any time. Do not carry these numbers into next year in your head. Carry the shape of the bill, which lasts, and go look the numbers up, which does not.

Where this site lies to you

Worth saying out loud, since you have probably already been playing in the lab on this site. It builds a knowledge graph instantly, for free, as many times as you like, and you will never see a bill.

That is because it is not a product. It is an in-memory teaching simulation. Your CSVs are parsed in your browser, the graph is built in a tab, and the whole thing disappears when you close it. No provisioned storage. No engine to keep warm. No floor, no meter, no rounding. Every cost this page just described is a cost the lab has quietly arranged for you not to feel.

That makes it a great place to learn what a graph is, and a bad place to learn what a graph costs. That gap is the reason this page exists. The model you build there is free. The same model, materialized in a product, sits there and bills.

The one trap

Do not budget a graph the way you budget a view.

A view's cost depends on use, so an unused view is a free view. You can leave a hundred of them sitting in a warehouse and never feel it. Every habit that taught you is wrong here. A graph's cost depends on existence. The unused graph is the expensive graph, because it pays its floor and its uptime and gives back only nine answers.

So the question to ask before you materialize is not "is this model any good." Yours probably is. It is "how many questions a month, and in what shape." Below the break-even, the honest move is to not build it yet, or to build it knowing exactly what you are buying: a fast answer to a question you are about to start asking a lot. Both are fine. Not knowing which one you did is not.

So the graph is up, warm, provisioned, and metered, and all of that spend buys exactly one thing. Next: the question itself, and the language you ask it in, GQL.