Frequently asked questions about Database Hub in Fabric (preview)

They are complementary. OneLake provides unified data storage for analytics. Database Hub provides unified operational control. They intersect through scenarios such as mirroring, analytics readiness, and inventory sharing. Database Hub isn't a data catalog. It focuses on operational metadata, signals, and actions. Where appropriate, it links to Purview or Fabric analytics experiences.

Database Hub is action-oriented but deliberately conservative. Actions are explicit and always approved by the end user (who must have the necessary permission to perform the action). Examples can include opening native surfaces and applying supported agent-proposed recommendations with confirmation. All actions respect role permissions and require approval. Database Hub validates intent and scope, then delegates execution to the authoritative service. Bulk actions and broader configuration changes can be introduced over time.

No. You don't need to relocate your databases. For example, on-premises SQL Server instances connect through Azure Arc and appear in Database Hub while remaining on-premises. Azure databases remain in their subscriptions. Database Hub centralizes operational metadata, signals, and actions. It doesn't centralize operational data. Fabric OneLake and Fabric mirroring can be used for analytics scenarios, but they are optional and separate from management.

Observability focuses on estate-level health and pressure signals such as CPU, I/O, connectivity, error conditions, posture, and utilization. These signals roll up into severity states that surface issues before charts. The goal is to identify where attention is needed and create a scoped view that people or agents can analyze. Advanced, engine-specific diagnostics remain available through native tools and are accessible through drill-through actions.

Third-party tools can provide deep capabilities for specific engines or environments and can require separate setup and infrastructure. Database Hub is built into the Microsoft platform and spans supported SQL, NoSQL, on-premises, Azure, and Fabric resources. It unifies inventory, scope, actions, and agent-driven insights and connects you to specialized native tools when deeper work is required. It doesn't aim to replace every specialized tool.

Database Hub supports both human-driven and agent-assisted workflows. Agents can consume Database Hub context, investigate findings, and propose actions, while execution continues to respect existing permissions and approval boundaries.

Yes. Copilot is the conversational interface. Agents are the analytical and operational engines behind it. Copilot provides grounded explanations and summaries using the same scoped data and agent findings visible in the UI. When Copilot recommends an action, it is backed by an explicit agent capability and an auditable proposal. There is no free-form execution.

Yes. In the current preview, Microsoft SQL databases require additional configuration. For instructions, see Add a Microsoft SQL database to the Database Hub.

No. Database Hub builds on these technologies rather than replacing them. Azure Arc remains the mechanism for connecting on-premises SQL Server instances to Azure. The Azure portal and native tools remain the authoritative surfaces for configuration and execution. Database Hub acts as a specialized control plane on top. It provides unified inventory, scoped context, agent-driven insights, and explicit actions, then routes execution to the correct native surface. You can continue to use the Azure portal, SSMS, Azure Data Studio, Visual Studio Code, and Fabric tools as before.

No. Database Hub is accessed through Microsoft Fabric, but it can discover Azure Cosmos DB accounts wherever they run in Azure. Those accounts remain in their existing subscriptions; discovery and estate monitoring do not require moving or mirroring their data into Fabric.

No. Detection is automatic for Azure Cosmos DB accounts, based on your existing Microsoft Entra ID and Azure RBAC permissions.

Estate lists Azure Cosmos DB accounts, not the databases or containers inside them.

No. Baseline discovery uses Azure resource inventory, and baseline monitoring uses existing Azure Monitor metrics. Fleet Analytics is a separate, opt-in pipeline.

For querying data in a database or container, your identity needs a separate Cosmos DB data-plane role assignment (or account keys, where allowed), plus network access to the account. Resource-level (management-plane) access, which is what makes an account visible in Estate, doesn't grant this.

Their Azure access, signed-in tenant, active filters, selected accounts, or time ranges can differ. Sharing a link or view doesn't grant additional access. Each person sees only the resources their identity is authorized to view.

Check the selected resources and filters. A dashboard value describes that selection, which can be narrower than the inventory in Estate.

The views can use different resources, time ranges, granularities, aggregations, or refresh times. Compare the same metric for one account over the same interval.

Neither. It means no usable value is available for that view. Check the selected interval, account activity, metric applicability by API type, access, and processing delay before drawing a conclusion.

The Performance dashboard focuses on account and estate-level metrics like RU consumption, throttling, latency, and availability. It doesn't provide query-level diagnostics, partition-key hot-spot analysis, or diagnostic log search. Use the Azure portal, Data Explorer, and Cosmos DB diagnostic logs for those investigations.

No. Use the Azure portal or your existing automation to change throughput for Azure Cosmos DB.

Do not assume parity. Audit logging isn't assessed for Cosmos DB yet. An unavailable assessment doesn't mean a control is disabled.

No. Use Database Hub findings as scoped guidance alongside the applicable service and security tools. The Cosmos DB monitoring workflow described here doesn't automatically remediate accounts.

SQL allocates capacity at database creation time in a single step. Cosmos DB separates a lightweight account-creation step (no throughput, no billing) from container creation, where throughput, partition keys, and indexing are configured and billing starts. Database Hub's inline create flow reflects only the first step; the second step provides a link to the Azure portal.

Yes. An account created from Database Hub is an Azure resource in the selected subscription. No charges accrue until a database and container with provisioned or autoscale throughput are created.

No. Database Hub is accessed through Microsoft Fabric, but it can discover supported Azure Database for PostgreSQL Flexible Server instances in Azure. Those servers remain in their existing subscriptions; discovery and estate monitoring do not require moving or mirroring their data into Fabric.

No. Detection is automatic for Azure Database for PostgreSQL flexible server instances, based on your existing Microsoft Entra ID and Azure RBAC permissions.

The PostgreSQL inventory entity is a Flexible Server instance. A server can host multiple databases. Do not interpret a count of servers as a count of application databases.

Baseline discovery uses Azure resource inventory, and baseline monitoring uses existing Azure Monitor metrics. You do not need Query Store, the SQL monitoring extended property, or an Arc installation. Tenant access and Azure resource/metric permissions still apply.

Azure resource access and PostgreSQL database access are separate. To connect, your client needs network reachability and an authorized database identity. Check the flexible server's authentication and network configuration without assuming that Estate visibility grants a connection.

Their Azure access, signed-in tenant, active filters, selected servers, or time ranges can differ. Compare these settings before assuming that resources or telemetry are missing. A shared link doesn't grant additional access.

Check the selected resources and filters. A dashboard value describes that selection, which can be narrower than the inventory in Estate. Also check for unavailable or inapplicable metrics before interpreting the value as a complete estate assessment.

The views can use different resources, time ranges, granularities, aggregations, or refresh times. Compare the same metric for one server over the same interval first. An estate summary isn't directly comparable to a single-server chart.

Neither. It means no usable value is available for that view. Check the selected interval, server state, metric applicability, access, and processing delay before drawing a conclusion.

Currently, Database Hub doesn't provide Query Store-backed top queries, query plans, wait-event analysis, or log search. Use the Azure portal and PostgreSQL tools for those investigations.

The SQL-specific monitoring templates and SQL ADX proxy are not part of the PostgreSQL Azure Monitor path. Activator alerting over these PostgreSQL metrics isn't currently supported. This limitation doesn't remove the service's separate Azure Monitor alerting options.

Do not assume parity. PostgreSQL supports these service features, but Database Hub assessment coverage is engine-specific. Review the applicable assessment and current server configuration. An unavailable CMK assessment doesn't mean encryption is disabled.

No. Use Database Hub findings as scoped guidance alongside the applicable service and security tools. Verify evidence and apply authorized changes through the appropriate service. The PostgreSQL monitoring workflow described here doesn't automatically remediate servers.

Yes. A Flexible Server created from Database Hub is an Azure resource in the selected subscription. Review its configuration and cost before deployment.

Related content

• What is the Database Hub?