Limitations in Microsoft Fabric mirrored databases from Google BigQuery

This guide helps you learn more about the existing limitations in your mirrored BigQuery in Microsoft Fabric.

Database level limitations

When mirroring tables without primary keys, you can only perform insert-only changes to ensure data accuracy. If non-insert changes are found, the table automatically reseeds (the table is remirrored in its entirely). If multiple non-insert changes occur following that initial reseed, Mirroring goes into a backoff state for a time; the backoff state helps keep down costs and limits unnecessary full-table replication. After the backoff period, the table will return to its normal state of Mirroring (continuous data replication).

Performance limitations

If you're changing most the data in a large table, it's more efficient to stop and restart Mirroring. Inserting or updating billions of records can take a long time.

Mirrored data typically reflects changes with a 10–15 minute delay due to BigQuery’s Change Data Capture (CDC) architecture. If no changes are detected, the replication engine enters a backoff mode, increasing polling intervals up to 1 hour.

Supported region limitations

Database mirroring is available in all Microsoft Fabric regions. For more information, see Fabric region availability.

Permissioning limitations

We understand that some customers are hesitant to enable edit permissions for Mirroring for Google BigQuery. Mirroring creates a live-twin, editable consumption replica of your BigQuery data in OneLake. To support Mirroring for Google BigQuery, the replication engine must:

• Access and export data from BigQuery tables
• Track changes using Change Data Capture (CDC)
• Create temporary datasets and jobs for replication
• Interact with Google Cloud Storage for staging and ingestion

Related content

• Google BigQuery mirroring overview
• Tutorial to set up mirroring for Google BigQuery