Fabric Performance Issue During GCP to Azure Migration: SELECT * from Views Hanging on F128 Capacity

[iamabhaykmr]

Hi,

We recently started our migration from GCP to Azure (Data Platform and Looker dashboards). Currently our F128 Fabric capacity is already running at around 80% utilization.

During the migration process, when we try to create gold layer tables from views (for example using SELECT * FROM view and inserting the results into Power BI gold layer tables), the query execution is taking 30 minutes to 1 hour. In some cases, the process hangs completely and leads to database deadlocks.

At the same time, several heavy reports are already running in other workspaces, so the overall capacity appears to be resource-starved. Because of this:

• Even simple queries like SELECT * FROM view hang.

• Sometimes even SELECT TOP (10) takes hours to execute.

• Queries occasionally get stuck indefinitely.

  Another random behavior we observed is that the same query against the same view scans different amounts of data on different days, even though the view definition and number of rows returned remain unchanged.

  Example:

   

  SELECT *
  FROM dese_gcp_prd.v_dcoe_omni_inv_db

   

  On different runs, the query scans different volumes of data, such as:

  • 0.5 GB

  • 2 GB

  • 4 GB

  • 6 GB

    However, the number of rows returned remains exactly the same.

    In BigQuery, this same query used to execute in under 2 minutes, but in Fabric the queries are either extremely slow or get stuck, which is impacting our migration timelines.

    Could someone please help explain:

    1. How the GB scanning and CU allocation mechanism works in Fabric?

    2. Why the same query might scan different volumes of data across executions?

    3. How capacity contention (CU starvation) affects query performance in this scenario?

       It would also be very helpful if you could share any in-depth documentation or articles explaining the Fabric compute model, CU allocation, and query execution behavior.

       Thanks in advance.

[v-prasare]

Hi @iamabhaykmr,

We would like to confirm if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[v-prasare]

Hi @iamabhaykmr,

We would like to confirm if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[v-prasare · Accepted solution]

Hi @iamabhaykmr,

Thanks for reaching out to MS Fabric community forum.

Try below troubleshooting steps and let me know if this helps:

When facing this issue, first review overall Fabric capacity usage and check whether CU utilization is consistently high during the failures. Identify if heavy reports, refreshes, or other workloads are running in parallel on the same capacity. Capacity contention can significantly delay or stall query execution.

Try isolating workloads by pausing or rescheduling heavy reports during migration runs, or moving migration jobs to a separate capacity. Avoid using Select *  on complex views where possible—explicitly select required columns or materialize views into intermediate staging tables.

Validate the behavior by running the same queries during low‑usage periods and compare execution time and scanned data volume. If performance stabilizes under low load, this strongly indicates CU starvation rather than a functional issue.

Also review for long‑running transactions or write‑heavy operations that could cause blocking or deadlocks while queries are hanging. Scheduling migration activities during off‑peak hours can help reduce contention.

Thanks,

Prashanth