OneLake: the unified foundation

A team spent a month on their ontology. Customer, Order, Shipment, every property named, every relationship drawn, keys chosen, the whole thing reviewed and signed off. It was genuinely good work.

Then they went to bind it to real data, and it all fell apart.

The customer data was in a data warehouse. Orders sat in an operational database that the app still wrote to all day. Product records were in a lake, in a different cloud than the rest. Support history came as a SaaS export, once a month, in a CSV nobody fully trusted. Two more databases held the rest. Six stores, six shapes, and no two of them agreed on which customer was which.

The ontology was a model of one clean business. The data was really six separate businesses stuck together. There was nothing single to bind to.

Meaning needs one place to stand

An ontology is a map of what things mean and how they connect. A map only helps if it points at one place. Point the same map at six places that disagree, and every road on it splits six ways.

That is the trap the team fell into. "A Customer places an Order" is a clean sentence, right up until you ask which customer table and which order store, and get six answers. The relationship did not fail. The data under it did.

So the real first step is not modeling. It is agreement. Get every source into one place, in one format, that everything reads the same way. Only then does binding mean anything. Only then is there a single row a concept can point at and say: that one, that is the Customer.

Bring it together, and the model has something to hold

Bring the scattered piles into one governed lake and the whole picture flips. Six stores become one logical copy. The splits turn back into single roads. And the ontology, which was floating uselessly above the mess, drops into place and binds every concept to the same source.

Two things make this a foundation and not just a folder. It is one place, so there is one truth to work with instead of six to line up. And it is governed, so who can see what, and where each value came from, travels with the data instead of being rebuilt for every copy. Meaning binds cleanly because underneath it, everything already agrees.

Try building it yourself. Start scattered, bring each source in, and watch one truth come together.

Notice what the counter did. The data came together, and almost nothing got copied. That is the part people miss: unifying your data and copying your data are not the same thing. You can make everything read as one without dragging every byte into one warehouse. The next layer turns exactly that difference into product.

In Fabric, that one place is OneLake

Microsoft Fabric builds this foundation in as OneLake: a single, unified, governed data lake, one per tenant (one per organization). Microsoft's nickname for it says it plainly: the "OneDrive for data." Every workload writes to the same lake, in the same open format, so the whole organization has one place to agree on instead of a store per team.

It keeps data in open Delta Parquet, a shared file format, not a closed vendor format. That openness matters for the same reason bringing the data together mattered: one format everything can read is what makes it one truth, not six copies that each read differently.

And it solves the scatter without forcing a big migration, using the two moves you just saw in the interactive.

A shortcut virtualizes data that lives elsewhere, in another cloud or another Fabric item, and points at it in place. No copy is made. The lake just reads through to it. Mirroring goes the other way for a live operational database: it continuously copies that database into OneLake, so the lake stays current while the source keeps serving its app. Together, they bring all your data together without a pile of stale copies drifting apart.

This is the ground floor of Fabric IQ. The ontology binds to OneLake tables. The knowledge graph materializes (is built) over them. The data agent, Fabric's name for an AI agent grounded in your data, reasons across them and answers in plain language. Behind the scenes, it turns your question into GQL, a standard graph query language. Every one of those layers assumes the thing underneath is single and governed. OneLake is what makes that true. One honest note on dates: OneLake itself is generally available, while the Fabric IQ workload above it is in preview as of July 2026, so treat its specifics as still changing.

The one trap

Do not confuse "we wrote the ontology" with "we have a foundation to build on." The model is the easy half to admire, because it looks clean on a whiteboard. The foundation is the half that decides whether any of it works, and you cannot see it until you try to bind. If your data still lives in six places that disagree, a beautiful ontology just gives you a beautiful description of a problem you have not solved yet. Unify first. Model second.

You have the ground. Now the very first thing you build on it is the smallest, sharpest decision in the whole model: what counts as a thing worth naming at all. That is the entity, and it comes next.