Before You Delete a Lakehouse in Fabric: A Mistake I Hope You Don’t Repeat
If you’ve worked with the SQL analytics endpoint in Microsoft Fabric Lakehouses, this post might not surprise you. But if you haven’t explored that part of the platform yet, I strongly recommend reading on — there’s a hidden risk you’ll want to avoid.
Did you know that when you connect to a Microsoft Fabric Lakehouse via the SQL endpoint — even through an external tool like SSMS — the SQL views you create are stored inside the Lakehouse itself?
I didn’t.
And that gap in knowledge led to a mistake I really hope you won’t repeat: I deleted a Lakehouse and unknowingly wiped out someone else’s work in the process.
This is a short story about how that happened — and a few lessons that might help you avoid doing the same.
🚧 The Cleanup That Went Wrong
If you’ve followed my content before, you know I care deeply about version control, automation, and CI/CD in the Microsoft Fabric and Power BI space.
That’s what made this mistake sting even more.
We were in the middle of a big cleanup and environment reset. The dev Lakehouse was cluttered with outdated tables, broken links, and stale data. CI/CD was already in place, but syncing changes from our Git branch kept failing due to conflicts with the existing Lakehouse.
To move forward, I made a judgment call: delete the Lakehouse and recreate it. It felt like a safe move — especially since all the “important stuff” was under source control.
Or so I thought.
A few hours later, someone on the team messaged me:
“Hey, where did all my views go?”
That’s when it hit me. The views he had created — via SSMS, using the SQL endpoint — were gone. And because they weren’t visible in the Fabric UI or tracked in Git, there was no way to recover them.
That message caught me completely off guard. We had never discussed anyone creating SQL views, and they weren’t part of the team’s documented workflow. So when that question popped up, it wasn’t just surprising — it was something I genuinely didn’t expect.
But this was a development workspace. And honestly, using dev environments to test or build things like SQL views is exactly what dev is for. The real issue wasn’t that someone created them — it was that I didn’t know they existed. And in shared environments, not knowing can be just as risky as making the wrong technical choice.
I hadn’t just cleaned up development clutter. I’d erased someone else’s work.
It was a sinking feeling — not because of technical complexity, but because it revealed a blind spot. I didn’t know those views were stored inside the Lakehouse, and nothing in the interface warned me otherwise. Everything looked fine.
It wasn’t.
That’s the danger: what you don’t see can absolutely hurt you.
🧨 The Unseen Risk
The root of the problem was simple — and invisible.
If you create SQL views (you can also create those via third-party tool like SSMS!), those views are not visible in the default Lakehouse view in Fabric - of course(?). You’ll see your tables, you’ll see your files, and you might assume that’s everything.
But if you switch to the SQL endpoint view. Once you’re in there, you’ll be able to see all the views and even the stored procedures.
And of course, if you're using SSMS to create or manage views, those same objects show up clearly:
So, while I thought I had full visibility into what was inside the Lakehouse, I didn’t. And when I deleted it, I unknowingly deleted SQL views someone else had created.
🔄 What CI/CD Doesn’t Cover (Yet?)
Even though source control was implemented in our Fabric workspace, it didn’t include SQL views created via the endpoint.
And that kind of makes sense. Views and stored procedures aren't files in the same way notebooks or semantic models are. But from a developer’s perspective, they’re still code — and often critical to the solution.
In this case, those objects existed entirely outside Git and outside Fabric’s primary UI — which made them dangerously easy to overlook.
- - Update this is what I tried to fix things:
I tried to bring the SQL views back and tried the obvious as described in the video below.
I also tried to use other pro-code solutions like the semantic-link-labs. The result was the same. And it’s not a surprise as the entire lakehouse was deleted, not just a table which can be restored (or at least there is the potential opportunity to do this).
🧠 A Blind Spot I Didn’t Know I Had
This wasn’t just a technical oversight — it was a blind spot.
I didn’t know those views could be created through the endpoint, and I definitely didn’t know someone had actually used that approach. That combination — not knowing what’s possible and not knowing what others are doing — is where the real damage happens.
This was one of those “unknown unknowns.” The kind that slip through even with CI/CD, automation, and a good process.
Now that I’ve seen it happen, I ask better questions. I double-check assumptions. I try to assume less.
And hopefully, now that you’ve read this, you will too.
🙋 Lessons I Learned
So what did I take away from all this?
Never assume the Fabric UI shows you everything. It doesn’t. In shared environments, always check the SQL endpoint — especially before making destructive changes. Views and stored procedures can quietly live there, completely out of sight.
Git doesn’t cover everything. If something isn’t file-based, it likely isn’t tracked in source control. That’s a blind spot you need to account for.
Before deleting anything shared, slow down. Ask around. Assume someone might be using it in ways you can’t immediately see. Most of the real risks aren’t technical — they come from assumptions, silos, and invisible dependencies.
If you're unsure whether someone else is using the Lakehouse for SQL views, ask.
Assumptions break more things than code ever will.
In fast-moving, collaborative environments, small oversights can turn into real consequences.
It’s not a mistake I want to make again — and it’s definitely not one I want you to make for the first time.