A few years ago I helped build a smart-building data platform from a pile of Azure services stitched together by hand — event ingestion here, a stream processor there, a warehouse for the modelled data, a separate store for the raw telemetry, and a great deal of plumbing in between to make them all talk. It worked. It even, eventually, talked back. But I remember exactly how much of the effort went not into the building's data problems and into the integration problems — the seams between the services, each excellent on its own and none of them designed to be each other's neighbour. So when a facilities-services engagement this summer gave me an excuse to point Microsoft Fabric at the same class of problem, I took it — with the large caveat that Fabric is still in preview, and preview is exactly where you kick tyres rather than sign things.

This is a field note from that tyre-kicking: what Fabric would genuinely have changed about the way I built that platform, and where it isn't ready to be trusted with it yet.

What the old build was fighting

To see what Fabric changes, you have to remember what the pain actually was. A smart building throws off a river of sensor telemetry — occupancy, temperature, CO₂, energy, door counts — and you need to do two quite different things with it at once: react to it now (the room's too warm, the floor's at capacity) and analyse it later (occupancy trends, energy patterns across seasons). Those two needs pulled the old architecture in two directions:

  • The real-time path wanted a streaming ingestion service and a stream processor, tuned for low latency.
  • The analytical path wanted a warehouse and a BI layer, tuned for big historical scans.
  • And the raw telemetry wanted somewhere cheap and vast to just land, because you never know which sensor reading you'll wish you'd kept.

Three stores, three tools, three copies of essentially the same data in different shapes — and an enormous amount of my time spent moving data between them and keeping the copies honest. The integration was the job. The building was almost a side quest.

What Fabric genuinely changes

The single idea in Fabric that matters most for this kind of work is OneLake — the notion that there's one storage layer underneath everything, and the various engines (the lakehouse, the warehouse, the real-time analytics, Power BI) all read and write the same copy of the data rather than each keeping its own. Plainly: one lake, many engines, no copying between them. For a smart-building platform, where my old pain was precisely the copying and reconciling between three stores, that's not a cosmetic improvement — it's aimed straight at the thing that cost me months.

A few pieces stood out in the preview:

  • Real-Time Analytics on the same lake. Fabric folds in a KQL-based engine — the same query language I fell for years ago on Azure Data Explorer — for the streaming, high-volume telemetry side, but sitting over the same OneLake as everything else. So the fast-reacting path and the slow-analysing path can, in principle, share one copy of the data instead of my old two.
  • Eventstream for ingestion without the plumbing. The preview's Eventstream feature is a low-code way to pull in streaming events and route them, which is a lot of the hand-wired ingestion glue from the old build turned into a few clicks. For a scenario that would still bring in IoT Central or an event hub at the building's edge, that downstream routing getting simpler is real.
  • One BI layer, no export. Power BI reading directly off the lake — Microsoft calls the direct mode Direct Lake — means the analytical dashboards don't need a separate warehouse copy to sit on. In the old build, that copy-for-BI was a whole refresh pipeline of its own.

Put together, a lot of the integration that dominated the original project is, in the Fabric telling, supposed to just not exist, because the pieces were designed as one platform rather than assembled from neighbours who'd never met. If that promise holds at scale, it genuinely would have saved me a chunk of that original build.

Where it isn't ready — and I'll say so

Now the honest half, because "would have saved me months" and "I'd put a building on it today" are very different claims, and Fabric is in preview. Kicking the tyres surfaced exactly the caveats you'd expect of a preview:

  • Preview means preview. Features move, behaviours change, and things that work this month may work differently next month. That's completely fine for evaluation and completely unacceptable for a production system a facilities team depends on at 2am. I would not run a live building on preview software, and neither should you.
  • The real-time story is the least mature part. For a smart building, the streaming, low-latency path is the demanding half — and it's also the newest, least-proven corner of the preview. The analytical side felt closer to ready than the real-time side, which is precisely backwards from where a building needs the most confidence.
  • The cost model is still a fog. Fabric's capacity model is new enough that predicting what a high-volume telemetry workload will actually cost, month on month, is guesswork right now. For a platform whose whole point is running continuously, "we're not sure what it'll cost" is not a footnote.
  • The migration question is unanswered. For the existing hand-built platform, there's no clean answer yet to "how would we move this onto Fabric," and I wouldn't pretend there is. Green-field evaluation is one thing; a migration path for a running system is another, and the preview isn't where you find it.
Fabric aims squarely at the exact pain that dominated my old smart-building build — the copying and stitching between too many stores. That's the right target. But "aims at" is a design promise, and preview is where you test the promise, not where you bet a building on it.

The verdict from the tyre-kicking

So: revisiting smart buildings with Fabric was genuinely clarifying, and my honest read is a split one. The architecture Fabric points toward — one lake, many engines, the integration designed away — is the architecture I wish I'd had for the original build, and if it lands the way the preview suggests, it removes the single biggest time-sink of that kind of project. That's exciting, and I don't say that lightly about a platform announcement.

But it is a preview, and I treat previews as previews: something to evaluate hard, prototype on, and form opinions about — not something to entrust with a live building this year. The right posture right now is to learn it, prototype against it, and watch — because the direction is right and the readiness is not yet there. When it goes GA, the question stops being "is this real?" and becomes "is this ready?", and that's the post I'll write then, once I can answer it honestly rather than hopefully. For now: promising tyres, and I'm keeping the car I've got.