How to handle BigQuery mirroring when the source has more than 1,000 tables?

VIGNESH G 40 Reputation points
2026-09-02T03:23:14.4133333+00:00

Hi,

We are setting up database mirroring in a Microsoft Fabric workspace, with BigQuery as the source.

Currently, our BigQuery source contains 1,193 tables, but a single mirrored database supports a maximum of 1,000 tables. Because of this limitation, we are currently able to mirror only 1,000 tables.

Our requirement is to mirror the complete source, including new tables that may be created in BigQuery in the future.

Could you please suggest the recommended approach for this scenario?

Specifically:

How can we mirror more than 1,000 BigQuery tables?

Is it recommended to create multiple mirrored databases and split the tables between them?

If we use multiple mirrored databases, how can we ensure that newly created tables in BigQuery are also automatically included in the mirroring?

Is there any other recommended approach or workaround for this limitation?

Any guidance or best practices would be greatly appreciated.

Thanks!

Azure Data Factory
Azure Data Factory

An Azure service for ingesting, preparing, and transforming data at scale.


3 answers

Sort by: Newest
  1. Himaja Y 375 Reputation points Microsoft External Staff Moderator
    2026-09-02T11:42:20.5466667+00:00

    HI @VIGNESH G ,

    Thank you for reaching out to the Microsoft Q&A forum. 

    The 1,000-table limit per mirrored database is currently a platform limitation in Fabric mirroring. Since your BigQuery source contains 1,193 tables, you'll need to split the workload across multiple mirrored databases to mirror all tables.

    Recommended approach:

    • Create multiple mirrored databases and distribute the tables between them (for example, by schema, domain, or business function).
    • Keep each mirrored database below the 1,000-table limit.
    • Monitor newly created BigQuery tables and add them to the appropriate mirrored database as needed.

    Important: There is currently no built-in mechanism to automatically redistribute tables across mirrored databases once the limit is reached. If your environment frequently adds new tables, consider implementing a monitoring/automation process to identify and onboard new tables.

    For long-term scalability, organizing tables logically across multiple mirrored databases is the recommended design pattern until support for larger table counts is available.

    I hope this helps! Please let us know if you need any assistance from my side.

    Was this answer helpful?

    0 comments No comments

  2. kagiyama yutaka 5,330 Reputation points
    2026-09-02T09:31:27.16+00:00

    I think Fabric mirrored db stops at 1,000 tables, and that limit can’t be raised. When BigQuery has more, run two mirrored dbs and a small job that reads the bq table list and adds new tables to whichever mirror still has room. That’s enough to keep the source covered as it grows, and Fabric doesn’t offer another way to go past the 1,000‑table limit.

    Was this answer helpful?

    0 comments No comments

  3. Senthil kumar 2,410 Reputation points
    2026-09-02T04:49:30.96+00:00

    Hi @VIGNESH G

    I understand your concern. I will explain you what are ways to fix this issue.

    • First and best approach, split your BigQuery into two queries 1) 1000 tables 2) 193 tables. suppose you now the table count this is approach is best. from function or any script get the table count and implement this approach.
    • Use Fabric Data Pipelines or Use a scheduled notebook or Use Azure Functions or Cloud Functions.

    Thanks.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.