December 23, 2025Uncategorized

Episode 313 – Microsoft Fabric November 2025 Feature Summary Part 1

In this episode, John & Jason talk about the Fabric news from Ignite: what’s new at the platform level, explore OneLake improvements, and break down the exciting developments in the databases space. With so much to cover from Ignite, they’ve split this into three episodes—so buckle up for a feature-packed analysis.

OneLake Platform Improvements

The team kicks off with platform-level features, and the first item on the agenda is Governed OneLake for tenant admins, which is currently in preview. Jason shares a practical real-world use case where he actually used this feature to check which workspaces were consuming their F2 capacity. Before diving deeper into the OneLake tab in the catalog, John points out an important caveat: the term “govern” might be a bit of a misnomer. It’s really about gaining insights into usage within your tenant rather than setting automation rules. Think of it as a visibility tool that helps you understand what’s happening across your Fabric infrastructure. The reports available here can help you make informed decisions—Jason found that only two workspaces were using their capacity, which gave him the confidence to pause it and reduce costs immediately. No automation, but definitely useful intelligence.

Next up is the ability to use a right-click tab menu for easier multitasking. While this sounds intuitive, Jason points out that it feels a bit odd in a browser context. When you right-click on tabs in the Fabric interface, the standard browser menu appears (refresh, save, etc.) rather than Fabric-specific options. The feature aims to let you pin tabs for quick access, but there’s already a hover menu pattern in other parts of Fabric that accomplishes similar goals. It’s an interesting addition, but the implementation feels slightly inconsistent with existing UI patterns.

On the source control front, Azure DevOps integration just reached general availability with some significant upgrades. You can now use a service principal against Azure DevOps for Git integration instead of requiring individual identities. Plus, it now supports cross-tenant scenarios. This is a big deal for organizations managing multiple tenants and using DevOps for their source control strategy. Jason emphasizes the importance of checking the documentation on automating Git integration using APIs—this is one of those areas where things evolve, and it’s worth reviewing the current best practices.

OneLake Diagnostics Goes GA

Here’s where things get interesting. OneLake Diagnostics is now generally available, and it’s generating some thought-provoking discussion between Jason and John. This feature captures diagnostic signals about OneLake activity and stores them in your own storage within Fabric. The key consideration is that it’s opt-in at the workspace level—you have to manually enable it.

Jason questions why this isn’t on by default, arguing that comprehensive logging and diagnostics should be foundational platform functionality. The feature enables federated data governance, operational transparency, and compliance reporting at scale—all things that feel like they should be baked into the platform rather than optional. However, John makes a solid counterpoint: it consumes storage and compute units, so there’s a cost consideration.

OneLake Diagnostics stores data as open JSON files in your lakehouse, making them queryable via Spark SQL, Event House, Power BI, or any tool that ingests JSON. This design choice seems intentional—Microsoft is creating space for third-party aggregation tools rather than building one themselves. Jason wonders why this isn’t routed through Event Stream to an Event House instead, but ultimately, the functionality is there for those who need comprehensive OneLake observability.

OneLake Security Gets Read/Write Permissions

Now we’re getting to something truly critical. OneLake security gains read and write permissions, and John emphasizes this is absolutely essential for the platform’s maturity. Previously, writing data to OneLake required contributor permissions on the workspace, which meant you had to grant create item permissions. This new feature decouples those permissions, letting you grant read and write access to OneLake data without allowing users to create new workspace items.

This opens up some powerful possibilities. Jason highlights that you can now leverage workspace identities for cross-workspace access without having to create security groups in Entra ID. Imagine you’re running reports in one workspace but need that same group to read data—or even write data back—from a different workspace. With workspace identity access to OneLake security, you can accomplish this more elegantly than before. As the platform marches toward ubiquitous OneLake security, this represents a major step forward for data governance maturity.

SQL Databases in Fabric: Transactional Data Meets Analytics

The databases section brings some genuinely exciting news: SQL databases in Fabric are now generally available. This represents a major milestone because Fabric is no longer just an analytics platform—it’s bringing proper transactional database capabilities into the ecosystem.

John explains the significance: when you create a SQL database in Fabric, the data is automatically mirrored to OneLake, making it immediately available to all Fabric tools for analysis. Everything lives under one umbrella now. You can build applications against Fabric SQL databases just like any traditional SQL Server, with all the transactional guarantees you’d expect.

Auditing and Compliance: The Critical Piece

However, Jason raises a crucial point. While SQL databases reaching GA is fantastic, the real blocker for production workloads has been the lack of auditing capabilities. That’s changing—SQL auditing is now in preview. Jason has already spoken with customers who were holding back from production deployments specifically because auditing wasn’t available. Without SOX, HIPAA, and other compliance certifications covered by auditing, enterprise teams can’t move forward. Now that auditing is in preview, these organizations can start building and testing with confidence, even if production deployments still need to wait for full GA.

Disaster Recovery and Data Protection

On the disaster recovery front, Microsoft has extended point-in-time recovery from 7 to 35 days. This is native retention on the platform—you’re not managing external logs, and it happens automatically. The question Jason raises is about cost implications. Extended retention consumes additional storage, and while the UI doesn’t show pricing details, it’s worth diving into the documentation and testing in a UAT environment before committing to full retention policies. Jason’s recommendation: don’t trust vendor calculators. Test it with real data in a real environment first.

Customer-Managed Keys and Encryption

Customer-managed keys (CMK) for SQL databases are now in preview. This gives you full control over encryption—you bring your own key and ensure that nobody, not even Microsoft, can access your data. CMK has been available in other areas of Azure and Fabric for a while, but having it from day one for Fabric SQL databases is a solid commitment to enterprise security.

Copilot Enhancements for SQL

On the intelligence side, Copilot sidecar chat has gotten capability improvements. The name might be new terminology, but the functionality is familiar—it’s that chat window that opens on the right where you can ask questions about your SQL databases in natural language. You can ask things like “find missing index recommendations for my database” or get performance analysis. Jason has already experimented with using Copilot to generate schema based on plain English descriptions, and it’s working well. This is particularly valuable for developers who aren’t expert SQL writers—let the AI handle the complex query generation while you focus on the data model.

Data Virtualization and External Tables

Data virtualization support for Fabric SQL databases brings external table functionality. This means you can query data that lives in OneLake as files (Delta, Parquet, or CSV format) through SQL without having to load it into the database itself. John points out that external tables behave like regular tables in SQL—they just happen to be slower since they’re reading from files. It’s a powerful pattern for ad hoc analysis and reduces the need to duplicate data.

Python Driver and Cosmos DB

The Microsoft Python driver for SQL Database is now generally available, enabling seamless interaction between Python notebooks and Fabric SQL databases. This is exactly what it sounds like: native SQL and Python integration.

And rounding out the databases announcements: Cosmos DB in Fabric is generally available. For teams working with NoSQL databases, this brings feature parity to the SQL database side. Jason jokes that this represents a 100% increase in available Fabric databases—from one (SQL) to two (SQL and Cosmos). Microsoft is clearly committed to supporting multiple database paradigms within the platform.

Looking Ahead

This is Part 1 of a three-episode deep dive into Ignite announcements. In upcoming episodes, Jason and John will tackle engineering features and then move into the broader Fabric ecosystem. There’s simply too much ground to cover in a single episode, so they’re chunking it down to keep each episode around 30 minutes and digestible.

If you want more detailed information on any of these features, check out the official Microsoft Fabric blog at blog.fabric.microsoft.com—many of these features have comprehensive deep-dive posts published alongside the Ignite announcements.

Resources and Further Reading

Subscribe: SoundCloud | iTunes | Spotify | TuneIn | Amazon Music

One Reply to “Episode 313 – Microsoft Fabric November 2025 Feature Summary Part 1”

Pingback: Episode 314 - Fabric November 2025 Feature Summary Part 2