Our organization has some very large Power BI datasets, and we ran into issues while testing a recent service pack when trying to test the Power BI refreshes against our non‑production environments. Those datasets were failing because non‑prod connections weren’t able to use the read-only connection which connects to a secondary node, which meant all testing traffic was hitting the primary node and competing with other for our environment.

Having a read‑only access option in non‑prod would let us test and validate Power BI models and queries using a connection to the secondary node, without triggering refreshes or write activity that can negatively impact performance. This gives us a much safer way to test large datasets and understand how reports will behave, without risking instability in the environment.

At the same time, we still need read/write/execute access in non‑prod for development work, configuration changes, and functional testing. The goal isn’t to replace that access — just to complement it.

By having both options available, we can:

• Test large Power BI datasets more reliably

• Avoid performance issues caused by refreshes during testing

• Use non‑prod environments more effectively without unnecessary failures

• Keep full development capabilities where they’re actually needed

This setup would make our non‑prod environments more stable, more realistic for analytics testing, and easier to work with overall.