Frequently asked questions for Microsoft Fabric mirrored databases from Azure Cosmos DB (Preview)

Mirroring replicates the source database into Fabric OneLake in open-source delta format. You can run analytics on this data from anywhere in Fabric. Shortcuts don't replicate the data into Fabric OneLake. Instead, shortcuts link to the source data without data movement. Currently, Azure Cosmos DB is only available as a source for mirroring.

No, mirroring doesn't affect the performance or cost of the source database. Mirroring requires the continuous backup feature to be enabled on the source Azure Cosmos DB account. Continuous backup enables replication without effect on transactional workloads.

Mirroring is a low-latency replication of your data in Azure Cosmos DB. Unlike copy jobs, mirroring creates a continuous and incremental copy of your Azure Cosmos DB data. Mirroring doesn't affect your transactional workloads on the source database or container.

In contrast, a copy job is a scheduled job, which can add end-to-end latency for incremental jobs. Additionally, copy jobs requirement management to pick up incremental changes, add to compute costs in Fabric, and affect request unit consumption on the source database in Azure Cosmos DB.

Copy jobs are useful for one-time copy jobs from Azure Cosmos DB, but mirroring is ideal for tracking incremental changes.

No, you can enable and disable mirroring without any effect to your source Azure Cosmos DB account or data.

Mirroring is in preview. There are currently no costs for compute used to replicate data from Azure Cosmos DB to Fabric OneLake. Storage costs for OneLake are also free upto certain limits. For more information, see OneLake pricing for mirroring. The compute for querying data using SQL, Power BI, or Spark is charged at regular rates.

For Azure Cosmos DB, continuous backup is a prerequisite to mirroring. If you enabled any continuous backup tier before mirroring, you don't accrue any extra cost. If you enable continuous backup specifically for mirroring, 7-day backup mode is free of cost; if you enable 30-day backup, you're billed the price associated with that feature. For more information, see Azure Cosmos DB pricing.

If you use data explorer to view the source data from Azure Cosmos DB, you will accrue costs based on Request Units (RU) usage.

Egress fees are only charged if your Azure Cosmos DB account is in a different region than your Fabric capacity. Fabric mirrors from the geographically closest Azure region to Fabric's capacity region in scenarios where an Azure Cosmos DB account has multiple read regions. For more information, see replication limitations.

No, mirroring doesn't use the analytical store. Mirroring doesn't affect your transactional workloads or throughput consumption.

In Azure Cosmos DB, continuous backup is a prerequisite for mirroring. This prerequisite allows Fabric to mirror your data without impacting your transactional workloads or requiring the analytical store.

No, mirroring in Fabric isn't related to Azure Synapse Link.

In Azure Cosmos DB, continuous backup is a prerequisite for mirroring. This prerequisite allows Fabric to mirror your data without impacting your transactional workloads or requiring the analytical store.

No, mirroring in Fabric isn't related to Azure Synapse Link. You can continue to use Azure Synapse Link while using Fabric mirroring.

Yes, you can use analytical store and Fabric mirroring on the same Azure Cosmos DB account. These features work independently of each other. Mirroring doesn't interfere with analytical store usage.

Yes, you can use the change feed and Fabric mirroring on the same Azure Cosmos DB account. These features work independently of each other. Mirroring doesn't interfere with change feed usage.

Mirroring requires Azure Cosmos DB continuous backup as a prerequisite. Azure Cosmos DB accounts with continuous backup enabled can't disable analytical store. Once you disable analytical store on any collections, you cannot enable continuous backup. This is a temporary limitation.

No, Azure Synapse Link and Azure Synapse Analytics are still available for your workloads. There are no plans to deprecate these workloads. You can continue to use Azure Synapse Link for your production workloads.

In the Fabric portal, select the Manage connections and gateways options within the Settings section.

Only read-write account keys are supported.

No, only read-write account keys are supported at this time.

No, only read-write account keys are supported at this time.

You must update the connection credentials for Fabric mirroring if the account keys are rotated. If you don't update the keys, mirroring fails. To resolve this failure, stop replication, update the credentials with the newly rotated keys, and then restart replication.

No, when you mirror a database from Azure Cosmos DB, all containers are replication into Fabric OneLake.

Yes, multiple mirrors are possible but unnecessary. Once the replicated data is in Fabric, it can be shared to other destinations directly from Fabric.

No, mirroring doesn't support the creation of shortcuts to external sources like Azure Data Lake Storage (ADLS) Gen2 or Amazon Web Services (AWS) Simple Storage Service (S3).

The option in Fabric to view the source database provides a read-only view of the live data in Azure Cosmos DB using the data explorer. This perspective is a real-time view of the containers that are the source of the replicated data.

This view of the live data directly in the Fabric portal is a useful tool to determine if the data in OneLake is recent or represented correctly when compared to the source Azure Cosmos DB database. Operations using the data explorer on the live Azure Cosmos DB data can accrue request unit consumption.

Use the Fabric portal create a new SQL query against your SQL analytics endpoint. From here, you can run common queries like SELECT TOP 100 * FROM ....

Additionally, use Lakehouse to analyze the OneLake data long with other data. From Lakehouse, you can utilize Spark to query data with notebooks.

The syncing of the data is fully managed. When you enable mirroring, the data is replicated into Fabric OneLake in near real-time and mirroring continuously replicates new changes as they occur in the source database.

Mirroring is supported across regions but this scenario could result in unexpected network data egress costs and latency. Ideally, match your Fabric capacity to one of your Azure Cosmos DB account's regions. For more information, see replication limitations.

You can add existing mirrored databases as shortcuts in Lakehouse. From Lakehouse, you can explore the data directly, open the data in a notebook for Spark queries, or build machine learning models.

The latency of initial and continuous replication varies based on the volume of data. In most cases, latency can be a few minutes but it can be longer for large volumes of data.

Once the initial data is replicated, individual operations are replicated in near real-time. In rare cases, there can be a small delay if the source database has a high volume of update and delete operations within a time window.

No, mirroring doesn't have built-in backoff logic as replication is continuous and incremental.

No, mirroring doesn't currently support the change data feed on mirrored data from Azure Cosmos DB.

Mirroring doesn't have built-in support for the medallion architecture. You can configure your own silver and gold layers with watermark logic and processing for transformations and joins using pipelines or Spark.

Yes.

Yes, nested data is flattened in OneLake as a JSON string. Use OPENJSON, CROSS APPLY, and OUTER APPLY to flatten the data for view. For more information, see nested data.

No, mirroring doesn't automatically flatten nested data. Methods are available for the SQL analytics endpoint to work with nested JSON strings. For more information, see nested data.

No, in general SQL queries in Fabric don't experience cold start latency.

Data Explorer and replication begin to fail in Fabric. OneLake data remain as-is, until you delete the existing mirrored data.

Connecting to the SQL analysis endpoint for mirrored data is similar to using the same endpoint for any other item in Fabric. For more information, see connect to data warehousing in Fabric.

Mirror each Azure Cosmos DB database independently. Then, add one of the SQL analytics endpoints to the other as a mirrored database item. Next, use a SQL JOIN query to perform queries across containers in distinct Azure Cosmos DB databases.

Mirror the Azure Cosmos DB database. Then, mirror either the Azure SQL database or Snowflake data. Then, add one of the SQL analytics endpoints to the other as a mirrored database item. Now, use a SQL JOIN query to perform queries across multiple data services.

Stop replication by using the Fabric portal's stop replication option. This action completely stops replication but not remove any data that already exists in OneLake.

Replication doesn't support the concepts of pause or resume. Stopping replication completely halts replication and selecting restart replication in the Fabric portal starts replication entirely from scratch. Restarting replication replaces the OneLake data with the latest data instead of incrementally updating it.

Mirroring for Azure Cosmos DB automatically mirrors all containers within the selected database. Because of this nuance, the Fabric portal doesn't contain an option to configure specific replication options for Azure Cosmos DB.

Optimally, you want the replication to have a status of Running. If the replication status is Running with warning, the replication is successful but there's an issue that you should resolve. A status of Stopping, Stopped, Failed, or Error indicates more serious states that require intervention before replication can continue. For more information, see Monitor Fabric mirroring.

Yes, data deleted using TTL is treated in the same way as data deleted using delete operations in Azure Cosmos DB. The data is then deleted from the mirrored database. Mirroring doesn't distinguish between these deletion modalities.

Delete operations are replicated immediately to OneLake. There's currently no way to configure soft-deletes or analytical time-to-live (TTL).

No, analytical time-to-live isn't supported.

Yes, you can access OneLake files directly using the file or storage explorers. You can also use OneLake delta files in Databricks. For more information, see access Fabric data directly using OneLake file explorer or integrate OneLake with Azure Databricks.

No, support for automated mirroring configuring is currently not available.

No, support for built-in CI/CD is currently not available.

No, this level of access is currently not supported.

No, private endpoints are currently not supported.

No, data remains in your Fabric tenant.

No, data is staged directly in your tenant's OneLake and isn't staged outside of your environment.

Power BI Premium, Fabric Capacity, or Trial Capacity licensing is required to use mirroring.

For information about licensing, see Fabric licenses.

For information about licensing, see Fabric licenses.

Related content

• Overview of Microsoft Fabric mirrored databases from Azure Cosmos DB
• Troubleshooting: Microsoft Fabric mirrored databases from Azure Cosmos DB
• Limitations: Microsoft Fabric mirrored databases from Azure Cosmos DB