Microsoft Fabric Database Hub: A Unified Control Plane for the Modern Database Estate
Introduction Organizations today manage an increasingly complex database landscape. Mission-critical data lives across Azure SQL Database, SQL Server, Azure Database for PostgreSQL, Azure Cosmos DB, Fabric databases, and various on-premises environments. While each platform serves important business needs, managing them often requires separate monitoring tools, governance frameworks, operational processes, and administrative experiences. As enterprises accelerate their AI and data transformation initiatives, fragmented database management becomes a significant challenge. Database administrators, platform teams, and data leaders need a unified way to understand the health, security, performance, and operational posture of their entire database estate. Microsoft Fabric Database Hub addresses this challenge by introducing a centralized database management experience inside Microsoft Fabric. Rather than managing databases through multiple portals and disconnected tools, organizations gain a single operational experience to discover, observe, govern, and optimize databases across cloud, on-premises, and Fabric environments. What is Microsoft Fabric Database Hub? Database Hub is a unified operational experience within Microsoft Fabric that provides centralized visibility into an organization's database estate. The Database Hub enables customers to: Discover databases across multiple platforms Monitor performance and health Identify operational risks Improve governance and compliance Receive AI-assisted recommendations Investigate issues across environments Prioritize remediation activities Instead of jumping between Azure Portal, SQL Management tools, monitoring platforms, and Fabric workspaces, administrators gain a single pane of glass for database operations. The vision is simple: One place to see the estate, understand what matters, and take the next best action. Why Database Hub Matters The Challenge of Database Fragmentation Most enterprises operate hundreds or even thousands of databases across multiple technologies: Azure SQL Databases Azure SQL Managed Instances SQL Server Azure Database for PostgreSQL Azure Cosmos DB SQL Database in Fabric Hybrid and Arc-enabled deployments Each platform typically has: Separate monitoring tools Separate security dashboards Different governance processes Different performance views Different troubleshooting experiences As AI initiatives expand, organizations require broader visibility across operational and analytical systems. Database Hub brings these experiences together. A Strategic Shift Historically, organizations focused on managing individual databases. Database Hub introduces a new operational model: Manage the entire database fleet rather than managing databases one at a time. This estate-first approach enables platform teams to: Identify systemic issues Prioritize risks Establish governance standards Improve operational consistency Scale DBA operations efficiently Supported Database Platforms Database Hub provides a unified view across Microsoft database technologies including: Azure SQL Database Azure SQL Elastic Pools Azure SQL Managed Instance SQL Database in Fabric Azure Cosmos DB Azure Database for PostgreSQL SQL Server enabled by Azure Arc SQL Server running on Azure Virtual Machines This broad support allows customers to modernize at their own pace while maintaining visibility into legacy and modern environments. Key Capabilities 1. Estate-Level Visibility One of the most powerful capabilities of Database Hub is estate-wide visibility. Database administrators can: View all databases in a single inventory Search and filter resources Group databases by platform Understand deployment distribution Assess operational health Instead of reviewing systems individually, administrators gain immediate visibility across their entire estate. 2. Centralized Monitoring Database Hub introduces a consolidated monitoring experience. Teams can analyze: Database health Availability indicators Capacity trends Utilization metrics Resource consumption Performance patterns The platform helps identify emerging issues before they become business-impacting incidents. 3. Unified Performance Insights Performance data is often scattered across multiple monitoring tools. Database Hub provides: Estate-wide performance visibility Cross-database trend analysis Real-time monitoring Historical performance analysis Administrators can quickly understand: Which databases require attention Performance degradation trends Resource bottlenecks Optimization opportunities 4. Issues and Recommendations Database Hub automatically surfaces: Issues Issues represent conditions requiring immediate attention: Security concerns Configuration problems Performance degradation Availability risks Operational anomalies Suggestions Suggestions identify opportunities for improvement: Performance tuning Cost optimization Security enhancements Utilization improvements Best-practice recommendations This helps teams move from reactive operations to proactive optimization. 5. AI-Assisted Database Operations One of the most exciting innovations is the integration of AI-driven assistance. Database Hub leverages intelligent database agents and Copilot-powered experiences to help users: Understand operational changes Investigate risks Diagnose issues Recommend corrective actions Identify optimization opportunities Rather than simply displaying metrics, the platform helps explain: What changed Why it matters What action should be taken This dramatically reduces time-to-resolution and accelerates troubleshooting. 6. Governance and Compliance Visibility Governance remains a top concern for regulated organizations. Database Hub supports: Centralized governance visibility Security posture monitoring Policy reporting Compliance tracking Risk identification Importantly, organizations can maintain their existing governance and operational models while benefiting from centralized observability. This is particularly valuable for industries such as: Oil & Gas Energy Financial Services Healthcare Government Manufacturing 7. Hybrid and Multicloud Awareness Many organizations continue operating hybrid environments. Database Hub acknowledges this reality by providing visibility across: Cloud databases On-premises databases Arc-enabled environments Fabric-native databases Customers gain a consistent operational experience without requiring workload migration. How Database Hub Fits into the Fabric Vision Microsoft Fabric is evolving into a unified data platform that combines: Data Engineering Data Factory Data Science Real-Time Intelligence Power BI OneLake Fabric Databases Fabric IQ Database Hub extends this strategy by integrating operational databases into the broader Fabric ecosystem. The result is a platform that spans: Operational Data Transaction processing Business applications Line-of-business systems Analytical Data Warehouses Lakehouses Power BI models AI Workloads Intelligent applications Retrieval-Augmented Generation (RAG) Agentic AI solutions Copilot experiences Database Hub serves as the operational bridge connecting these worlds. Benefits for Customers For Database Administrators Single management experience Faster troubleshooting Estate-wide visibility Reduced tool sprawl For Platform Teams Centralized governance Consistent operational standards Improved fleet management For Executives Better operational risk visibility Improved compliance posture Greater operational efficiency AI-ready database strategy For Data and AI Teams Better connection between operational and analytical systems Easier integration with OneLake Faster access to enterprise data Improved AI readiness Real-World Customer Scenario Consider a global energy company running: SQL Server on-premises Azure SQL Managed Instance Azure Database for PostgreSQL Azure Cosmos DB Fabric Databases Traditionally, each environment requires separate management processes. With Database Hub, the organization can: Discover all databases from one location. Monitor estate-wide health and performance. Identify security and compliance gaps. Receive AI-generated recommendations. Investigate issues before they impact production. Prioritize remediation activities across the entire portfolio. This shifts operations from reactive administration to intelligent estate management. The Future of Database Operations The database landscape is becoming more distributed and complex. At the same time, organizations expect: Greater reliability Lower operational costs Stronger governance Faster innovation AI-driven insights Database Hub represents Microsoft's vision for the future of database operations: A unified, AI-powered control plane capable of managing the complete database estate regardless of where workloads run. As organizations continue their modernization journey, solutions like Database Hub will become increasingly important for maintaining visibility, governance, and operational excellence. Final Thoughts Microsoft Fabric Database Hub is more than another management portal. It is a strategic evolution in how organizations operate, govern, and optimize their database estates. By bringing Azure, Fabric, SQL Server, PostgreSQL, Cosmos DB, and hybrid environments into a single operational experience, Database Hub empowers teams to move from fragmented database administration to intelligent estate-wide operations. For organizations pursuing data modernization and AI transformation, Database Hub provides a critical foundation: visibility, governance, observability, and actionability across the entire database landscape. In the era of AI, the winners will not simply be the organizations with the most data. They will be the organizations that can understand, govern, and operationalize their data estate most effectively. Database Hub in Microsoft Fabric is designed to help them do exactly that.
Enhancements for Excel Pivot Table Connectivity to Semantic Models
The business needs Excel to perform on Fabric The Problem: Unoptimized Capacity Consumption and Performance Bottlenecks While Excel's live connection to Fabric Semantic Models is a key feature, it currently presents a significant challenge for enterprise-level deployments, primarily related to performance and the unoptimized use of Fabric capacity. The core issue is that the current connection method, which relies on the XMLA endpoint and MDX query translation, leads to: * Excessive Capacity Consumption: Every user interaction—from dragging a field to applying a filter—generates an independent, and often verbose, MDX query that is translated and executed. This constant, unoptimized querying on a per-user, per-click basis results in a high number of interactive queries, which are the most expensive type in Fabric capacity. * Poor User Performance: As a result of the unoptimized queries, users experience frustratingly slow response times. A simple action that should be near-instantaneous can take several seconds to complete, especially with complex semantic models and multiple concurrent users. This degrades the user experience and can lead to a lack of trust in the centralized data model. The Proposed Enhancement: A Modern, Optimized Connection Layer We request the development of a new, modernized connection layer for Excel that is purpose-built for Fabric Semantic Models. This would move beyond the legacy MDX translation approach and provide a more intelligent and efficient way for Excel to interact with the service. Key features of this enhanced connection layer should include: * Smart Query Batching: Implement a mechanism to intelligently batch multiple user actions into a single, optimized query to the Fabric service. This would significantly reduce the number of interactive queries, lowering capacity consumption and improving performance. * Native DAX Support: Instead of translating MDX to DAX on the server, allow Excel to generate optimized DAX queries directly from the client. This would eliminate a performance bottleneck and ensure that the queries are written in a way that best leverages the semantic model's structure. * Improved User Experience: A faster, more responsive connection would dramatically improve the user experience, encouraging broader adoption of Fabric as the go-to platform for data analysis in conjunction with Excel. Business Impact: Unlocking True Enterprise Scalability This enhancement is not just a "nice-to-have"; it is critical for unlocking the true enterprise scalability of Microsoft Fabric. A modern, performant connection between the world's most popular spreadsheet tool and Microsoft's unified data platform would: * Reduce TCO: By consuming capacity more efficiently, organizations can get more value from their Fabric investment and manage costs more effectively. * Boost Productivity & Trust: Faster performance means business users can work more efficiently, building trust in the centralized data model and reducing reliance on manual, ad-hoc data sources. * Strengthen the Microsoft Ecosystem: This would further cement the powerful synergy between Fabric and Office, demonstrating a seamless and high-performance experience for the millions of users who rely on both products daily. Summary: Everyone agrees, Excel is not going away. Optimizing Excel's connectivity to Fabric Semantic Models for capacity and performance is essential. We urge the Fabric team to prioritize the development of a modern, efficient connection layer that will not only solve current user frustrations but also enable organizations to confidently scale their analytics solutions. Fabric has gone miles beyond a reporting tool as it has evolved into Fabric, these changes fully fit within the scope of providing a robust end to end Analytics platform.Streamlining Power BI Tenant Inventory Management Using a REST API Connector
Background & The Challenge In one of my projects as a Power BI Administrator, a common requirement was to maintain a comprehensive inventory of tenant assets, including workspaces, reports, datasets, dashboards, and capacity metrics. Historically, my team handled this using a legacy, multi-step extraction process: Data Extraction: Running manual PowerShell scripts to call various Power BI REST API endpoints. Storage: Dumping the raw JSON outputs into a SQL Server database. Analysis: Writing ad-hoc SQL queries against the database whenever we needed specific inventory information. Action: Using this queried data to perform quarterly clean-up tasks (e.g., deleting orphaned workspaces, updating capacity assignments, and removing unused reports). The Pain Point This legacy approach was highly inefficient. Every time we needed updated inventory data, an admin had to validate the PowerShell scripts, manually execute them to refresh the SQL database, and then write or run SQL queries to get actionable insights. The data was often stale, and the process was too reliant on manual intervention. The Proposed Solution To eliminate the manual overhead and the need for external database storage, I designed a streamlined solution: Consolidating the inventory tracking directly into a Power BI report using a Custom Connector. Instead of pushing API data out to SQL via scripts, the solution pulls the data directly into Power BI: Custom Power BI Connector: I developed a custom connector designed specifically to authenticate and call the required Power BI REST API endpoints (Workspaces, Datasets, Reports, etc.). Direct Reporting: I built an end-to-end Power BI report that consumes data directly from this custom connector, visualizing all necessary inventory and capacity metrics in one place. Automated Refresh: I configured an On-Premises Data Gateway connection to allow the dataset to refresh automatically on the Power BI Service. The Value Add Zero Manual Intervention: No more managing or executing PowerShell scripts. The data stays fresh via standard Power BI scheduled refreshes. Self-Service Access: Whenever stakeholders or admins need inventory details for quarterly cleanups, they simply open the shared Power BI report. Actionable Insights: Admins can instantly identify unused assets, capacity bottlenecks, and workspace bloat without writing a single SQL query. Key highlights: 🔐 Azure AD OAuth2 - no client secrets, no passwords 📄 Full inline documentation inside Power BI Desktop 🔄 Auto-pagination for large tenant environments ⚡ Works with both Desktop & On-premises Data Gateway Some Screenshots of POC I successfully built and tested this approach as a Proof of Concept (POC) end-to-end. I am sharing this idea with the Fabric community for others who might be struggling with tenant inventory management and looking for a more automated, native reporting approach. Hopefully, This will be help lot of members who is facing similar type issues if Microsoft team can officially launch this connector so everyone can just use and do whatever they need. Quick Update: I have created the custom conenctor for the Power BI as well as Fabic REST endpoints. As of not it covers... -> 56 Power BI REST API functions (Datasets, Reports, Dashboards, Pipelines, DAX execution & more...) -> 53 Microsoft Fabric functions (Lakehouse, Warehouse, Eventhouse, KQL & more...) Shoutout / Special Thanks: Boston Office D365 User Group www.youtube.com/@BostonOffice365UserGroup Note: AI was used to assist in formatting and refining this post for clarity.Built a free tool to inventory & risk-rate legacy SSIS packages before a Fabric migration
Hi all, Sharing something I built that might save some of you the painful "open every .dtsx in SSDT one by one" phase of an SSIS → Fabric migration. The problem it addresses: most teams sitting on a legacy SSIS estate have dozens to hundreds of undocumented packages and no clear starting point. Before any actual migration work, someone has to answer: what does each package do, which components map cleanly to Fabric, and which need a full rewrite? What it does: Parses .dtsx package XML and extracts control flow tasks, data flow components, connection managers, variables, and precedence logic Maps each component against a Fabric equivalent — Data Flow Task → Dataflow Gen2, Execute SQL Task → Script/Stored Procedure Activity, Script Task → Notebook Activity, Foreach Loop → ForEach Activity, and so on Gives each package a Low/Medium/High risk rating based on concrete signals (Script Task usage, Fuzzy Lookup, deprecated CDC/Attunity components, nesting depth, dynamic connection strings) Flags every component individually as auto-mappable or needs-manual-redesign, not just the package as a whole Across a batch of packages, produces a portfolio rollup: risk tier counts, the blockers showing up across the most packages, deprecated components flagged separately, and a suggested migration order What it's built as: a Claude Skill (Anthropic's Claude AI), with the actual XML parsing done by a plain Python script with zero dependencies — not an LLM guessing at package structure. It's designed to run fully offline, no live Azure/Fabric API access assumed, though it flags anywhere that access would improve accuracy (resolving a dynamic connection string, for example). What it deliberately doesn't do yet: this covers the Inventory/Classify phase only. It won't draft actual Fabric pipeline JSON or claim a package is production-ready — every future draft artifact gets an explicit DRAFT/NEEDS REVIEW label. I'd rather it under-claim than over-claim. Repo's on GitHub with a sample package and example report included, so you can see the actual output before running it against your own packages: https://github.com/HBBH11/ssis-fabric-migration-assistant Genuinely interested in feedback from people who've done these migrations for real — particularly whether the risk heuristics hold up against messier packages than my test case, and whether the Fabric equivalence mappings match what you've found in practice. Happy to take suggestions on what a Phase 2 (draft pipeline generation) should prioritize too.
Allow Downloading Power Query (M) Transformations Along with Power BI Reports from the Service
Category: Power BI Service / Data Connectivity Description: Hi Power BI Community Team, I would like to suggest a feature enhancement for Power BI Service that would be useful for Power BI developers, BI teams, and report maintainers. Currently, when downloading a report from Power BI Service, users working with live-connected reports may not receive the underlying semantic model or its Power Query transformations. It would be helpful if Power BI Service provided an option to export the associated Power Query M scripts along with the report, subject to the user's permissions and the semantic model's configuration. Proposed Enhancement: Allow users to export Power Query M scripts associated with the underlying semantic model when downloading a report from Power BI Service. The export could be provided as a separate .pq or .txt file, or as part of a fully editable PBIX download wherever supported. The export should preserve query names, transformation steps, and query dependencies. Business Value: This feature would help developers understand and maintain existing ETL logic, reduce the effort required to recreate transformations when the original PBIX file is unavailable, and support troubleshooting, report migration, documentation, and knowledge transfer. For example, when a developer downloads a live-connected report from Power BI Service, having an authorized way to retrieve the Power Query transformations would eliminate the need to locate the original PBIX file or contact the original report developer. I understand there may be technical and security considerations. Even a separate, permission-controlled export of Power Query M scripts would be a valuable enhancement. Could this functionality be considered for a future Power BI update? Thank you for your time and consideration.
Request to add a feature to extract gateway connection status and last time credentials used
Could you please add a feature in the admin UI on Microsoft Fabric/Power BI to extract the Gateway connections with details of the gateway connection status and last activity information along with the connection name, users, and connection type. Current Limitation Administrators can manage gateways through the Power BI Service, but there is currently no simple way to use PowerShell to extract operational details such as: Gateway connection status (Online/Offline) Last successful connection timestamp This capability is important for our internal stakeholders from an audit and governance perspective, as it would help maintain a streamlined and well-governed Power BI environment. As part of the company's cloud modernization initiative, our internal teams are planning to extract connection information to identify which connections are still required and which can be safely decommissioned. This analysis is necessary to identify on-premises server dependencies and develop a migration plan to the cloud. Currently, because there is no way to determine which connections are active and which are inactive, it looks like the exercise becomes complex. Having this functionality available would greatly improve visibility, governance, and migration planning efforts. Thanks.Mirroring for Google BigQuery in Microsoft Fabric (Generally Available)
Mirroring for Google BigQuery in Microsoft Fabric is now generally available. For organizations running critical workloads on BigQuery, this means a simpler, faster, and lower-cost path to bringing your data into the rest of your analytics estate — with production support, an enterprise SLA, and no pipelines to build or maintain.
Support Fabric SQL Database with workspace-level inbound Private Link
Fabric SQL Database supports tenant-level Private Link but not workspace-level Private Link. Securing a small number of databases therefore requires enabling Private Link across the entire tenant, introducing unnecessary operational constraints for unrelated workspaces, Power BI workloads and on-premises data gateways.
Expose Power Query as a Standalone Runtime and Command-Line Interface (CLI)
Summary Power Query has evolved into one of Microsoft's most powerful data transformation technologies and is now used across Excel, Power BI, Fabric, Dataflows, Power Platform, and other products. However, Power Query can only be executed through a host application, despite the existence of a mature M language and execution engine. I would like Microsoft to expose the Power Query engine as a first-class standalone runtime and provide an officially supported command-line interface (CLI) and API. The Problem Today, Power Query transformations are often embedded inside: Excel workbooks Power BI Desktop files Fabric Dataflows Power Platform Dataflows While this works well for interactive users, it creates challenges for enterprise-grade automation. Many organizations would like to: Schedule Power Query transformations without opening Excel. Run Power Query from PowerShell scripts. Integrate Power Query into CI/CD pipelines. Execute transformations on servers without Office dependencies. Reuse Power Query code across multiple solutions. Treat Power Query as a reusable transformation layer rather than a workbook artifact. Currently, Power Query feels like a language without an officially supported runtime, even though the engine already powers multiple Microsoft products.
