After reviewing the details of your case and environment, I believe we’re aligned on the challenge you’re facing. Unfortunately, I need to share some difficult news: we’re unable to remove the current resource restrictions. This isn’t specific to your company; it’s due to the broader impact such a change would have on the entire system and all customers.
Removing these limits from your company’s database would require us to remove them for every company using this shared server. That would allow any company to consume resources without constraint, very quickly leading to server overloads and failures. In those conditions, the server can’t remain stable or responsive, which would negatively affect all clients—including you.
Right now, several clients share the same server you are on:
Some run well-optimized reports and queries that filter data down to a manageable number of rows.
Others run very complex queries directly in production, often without prior testing, significantly increasing the load.
And there are additional clients whose usage, while more moderate, still contributes to overall server strain.
To keep things fair and stable for everyone, we enforce resource constraints so each client can reliably access their fair share of server capacity. These constraints are essential not only when the SQL instance is under contention, but also for maintaining consistent quality of service across a diverse client base with very different usage patterns.
You’re absolutely right that this is not a data or environmental issue on your side. The key difference between the pilot and production environments is scale. The pilot environment has far fewer users and much lower traffic, so it doesn’t require the same constraints. Pilot typically runs at only about 35–45% of the traffic we see in production.
In theory, removing all constraints might seem beneficial, but in practice, the server becomes overwhelmed within 15–20 minutes. We’ve seen CPU utilization spike to 99% in that timeframe, leaving the server completely unresponsive. That data is what drives our need to keep the current resource constraints in place.
I recognize this isn’t the outcome you were hoping for, and I know that running your report in smaller chunks is not ideal. For example, processing 10 warehouses at a time or running for one week at a time across all 30 warehouses—and then applying your mathematical and statistical calculations—adds extra steps.
That said, this approach helps ensure the reports complete successfully rather than fail outright due to server overload. To make this as practical as possible, here’s a recommended workflow:
Narrow the report parameters into smaller segments, either by date range (e.g., one week at a time) or by warehouse groupings (e.g., 10 warehouses at a time).
Run each segment separately, keeping each query within the resource constraints so it can complete reliably.
Combine and refine the results from those smaller runs to create your full consolidated report.
For clients who truly cannot operate effectively within these shared-resource constraints, we do offer an Enterprise Cloud option. This provides you with a dedicated server, not shared with other clients. In that environment, we don’t need to apply the same resource restrictions because your usage alone determines how the server’s resources are consumed.
