16, April 2026
by: Stuart Haslam
Blog by Stuart Haslam
Attending FabCon and SQLCon 2026 in Atlanta was a useful reminder of how quickly the Microsoft data platform is moving. Recent updates like the Fabric March 2026 release are starting to show up in real use, not just in roadmaps.
Across both conferences, the energy was high and sessions were busy. There is clearly a lot of interest in data, analytics, and AI. More interesting though was how consistent the message was.
Simplify the architecture. Bring things together. Let teams move faster without losing control.
Which, to be fair, is what most organisations have been trying to do for years. It just tends to get complicated the moment real systems are involved.
There was also a good balance between strategy and delivery. Keynotes focused on direction, while breakout sessions and conversations with engineers and partners focused on what it actually takes to get there. Not everything is solved, but the direction is now clear.
Overall, this felt like a point where things are starting to line up. The platform is maturing, capabilities are coming together, and building something coherent is becoming more achievable.
If there was a single takeaway from FabCon, it is that Fabric is no longer just being positioned as a data platform. It is starting to act like something closer to an intelligence layer.
The announcements were not just feature updates. They point to a shift in how the platform is expected to be used. Embedded intelligence through Fabric IQ and agents, better interoperability, particularly with Databricks, and more consistent governance through OneLake.
Individually, none of this is entirely new. Together, it changes how you think about designing a platform.
Fabric IQ is really about moving beyond storing and processing data, and towards understanding it in a business context. Not as a separate capability, but as something that sits across the platform.
Things like ontologies and tighter integrations are part of that, but the bigger change is how AI starts to interact with the platform. Data Agents sit in the middle of that. They interpret logic, generate components, and take on some of the repetitive work that usually sits with engineers.
In practice, that means less time building the same patterns again and again, faster onboarding for new people, and more focus on outcomes rather than plumbing. Which sounds small, but is usually where things either get used or subtly abandoned.
There is also a shift happening underneath that. Work that used to move across engineering, modelling, and deployment in stages is starting to compress into a single flow. In some cases, you are going from question to output in a handful of steps rather than handing things between teams. It also starts to shift things from writing instructions to describing intent, which is a slightly different way of working.
Operations Agents take this a step further. Instead of analysing what has already happened, the platform starts to respond to what is happening. The gap between insight and action gets noticeably smaller.
That shift has been talked about for a long time. This is one of the first times it feels like it is being built into the platform rather than added on afterwards.
With the general availability of OneLake Governance and Security, Microsoft is addressing one of the biggest blockers to enterprise adoption, which is control without complexity. The key shift here is centralisation.
Instead of being spread across different tools, it is defined at the OneLake level and applied across the platform. The benefits are fairly apparent:
What’s particularly strong is how this aligns with other Fabric capabilities:
A lot of this is happening without physically moving data around. Data can stay where it is, and still be used properly.
One of the more interesting announcements was the bi-directional read and write capability between Fabric and Azure Databricks.
Most organisations already have multiple data estates. Rather than forcing a one platform wins approach, Microsoft is leaning into that reality. Fabric can read and write directly to Delta tables managed in Databricks, and Databricks can interact with data in OneLake.
Being able to read and write across both, without duplicating data, is a practical step forward. It means existing investments are not wasted and adoption can happen gradually without a complete overhaul. It also means teams can use the right tool for the job.
A lot of the announcements focused on something less flashy, but arguably more impactful day-to-day, which is developer productivity.
Fabric is clearly investing in reducing friction across the entire lifecycle. As such, they have made changes around deployment with selective branch checkout. You only deploy what you need. Fabric CLI is also enabling rapid environment promotion (Dev → Test → Prod in minutes).
None of this is particularly new, but it is the kind of thing that tends to make or break adoption.
There has clearly been a push to make Spark more usable at scale. High concurrency support, now up to 50 notebooks, alongside custom Spark pools with near-instant startup, starts to remove some of the waiting around that tends to slow teams down.
Runtime upgrades, including Spark and Delta Lake 4.x, are part of that, along with support for Z-Order and Liquid Clustering to improve performance and data organisation.
Taken together, it makes Fabric feel far more credible for proper engineering workloads, not just analytics layered on top.
Real-time capability is also being pushed further into the platform. With Eventstream and Spark structured streaming, alongside real-time hub business events like delays or threshold breaches, Fabric is moving closer to handling live operational scenarios.
Activator-driven alerts and automation then take that a step further, allowing responses to be triggered as things happen rather than after the fact. In some cases, that loop can now run without someone needing to step in. It can also feed results back into operational systems, rather than stopping at a dashboard.
The VS Code integration is one of those updates that sounds small, but will likely have a bigger day-to-day impact.
Being able to edit Fabric assets directly without downloads, work across notebooks in Python, SQL and Scala, and manage environments and monitoring in one place makes the experience much closer to how developers already like to work.
Adding Copilot with Fabric-aware context on top of that closes a gap that has been there for a while between data platform tooling and modern development workflows.
There is also a clear focus on making migration easier. Microsoft is putting more structure around moving from Synapse and Data Factory into Fabric, with migration assistants, support for SSIS and Mapping Data Flows, and early work on pre-migration assessments and selective migration.
The message is fairly straightforward. It is not just about building a new platform, but about making it easier to move existing estates across without having to start again.
When you step back, these announcements all point in the same direction: Fabric is becoming intelligent. It’s also becoming open and interoperable, enterprise-ready, and developer-first.
The traditional boundaries between data engineering, analytics, BI, AI and operations are starting to blur into a single, cohesive experience (and we’re personally delighted).
If FabCon focused on where analytics is going, SQLCon made something else clear. The database is not being left behind. It is moving at the same pace, becoming more connected, more integrated, and in some cases starting to take on a bit more of the work itself.
This is not just about performance or new features. It is about changing how SQL is used day to day. Less something you constantly manage, more something that can handle parts of that on its own.
SQL Server Management Studio 22 feels less like a typical upgrade and more like it catching up with how people already work. SSMS has always been capable, but it has also been fairly traditional. This starts to bring it closer to modern development practices.
GitHub Copilot now sits directly in the environment, helping with query writing and optimisation. SQL Projects bring proper source control, versioning, and deployment into SSMS without needing extra tooling.
None of this is new on its own, but having it all in one place makes it far easier to use. It also points to something that has been talked about for a while. Treating database work in the same way as application development.
Which sounds obvious, but does not always happen in practice.
The Model Context Protocol is one of the more forward-looking additions. It is still early, but the idea is simple. Give AI a better understanding of the database it is working with.
Instead of generating queries in isolation, it has more awareness of schema, relationships, and context. That leads to more accurate queries and fewer surprises when those queries run against real data.
In practice, this is less about making AI look clever and more about making it reliable enough to use properly.
A lot of the conversation at SQLCon came back to consolidation. Most organisations do not have one database, they have dozens, sometimes hundreds, across different environments.
The Database Hub in Fabric is an attempt to bring that into one place. A single view across on-prem SQL Server, IaaS databases, Azure services, and Fabric-native databases.
More importantly, it is not just about seeing what is there. It is about making that useful. Surfacing performance issues, flagging risks, and suggesting improvements in a way that can actually be acted on.
It also starts to move things towards a single place to manage all of that, rather than switching between tools depending on where things happen to live.
Database Agents build on that by taking a more active role. Instead of just flagging issues, they can investigate, suggest fixes, and sometimes act on them.
That includes detecting performance issues, working out what is causing them, and recommending or applying changes. In some cases, that can trigger follow-on actions like updating schemas or adjusting resources.
What stood out more this year is how quickly that moves from insight to action. It is not just highlighting issues, it is explaining what is going on, suggesting what to do next, and in some cases doing it.
Over time, it starts to learn how workloads behave and surface risks earlier. In effect, the environment becomes more self-observing, and in some places starting to feel a bit closer to self-healing than purely reactive.
SQL is also being pulled more tightly into the wider Fabric ecosystem. Migration paths into Fabric-based SQL databases, alignment with OneLake governance, and closer links with analytics and AI workloads all point in the same direction.
For organisations with existing estates, it means you do not have to start again. You can move gradually, run hybrid setups, and keep things working while you change them.
To sum it up, more of the day-to-day work is being handled by the platform itself, and less is left to manual intervention.
Which starts to shift things from reactive database management to something closer to continuous, AI-assisted optimisation.
That changes the shape of the role slightly. Less time spent fixing things as they break, more time thinking about how they are designed in the first place.
Have a question or want to make an enquiry?
Contact us
