When leadership asks how much runway you have on disk space, or whether you need to budget for more storage next quarter, how do you...
When leadership asks how much runway you have on disk space, or whether you need to budget for more storage next quarter, how do you answer that conversation today? For most DBA teams, the honest answer is some version of “let me check” — a quick manual pull of historical usage, a spreadsheet extrapolation, or, more often than anyone wants to admit, a gut-feel estimate based on when the last storage request went through.
That gap between “I’d have to go check” and “here’s exactly what’s happening and when we’ll need to act” is what SQL Server capacity planning and growth forecasting are built to close — and the tutorial Capacity Planning with SQL Diagnostic Manager for SQL Server from IDERA Data Tools walks through exactly how.
SQL Server capacity forecasting works by projecting disk growth, database growth, and table growth forward in time based on actual, historical growth patterns already collected by SQL Diagnostic Manager — not estimates or manual spreadsheet extrapolation. Using Linear or Exponential forecasting, it identifies which databases and tables are expanding fastest and estimates when available space will run out, turning routine monitoring data into a proactive capacity-planning tool.
Have you ever been caught off guard by a database or storage issue that, in hindsight, had been quietly building for weeks? It is one of the most common stories DBAs share, and it almost always follows the same arc: a volume fills up faster than expected, a table balloons past what anyone remembered provisioning for, and the first anyone hears about it is an alert that something is nearly out of room — not a heads-up that it was trending that way.
The frustrating part is that the warning was almost always available. Growth rarely happens overnight. A database that runs out of space this month was very likely growing at a measurable, trackable rate for the two or three months before that. The problem is not a lack of data — it’s that the data was sitting in performance history nobody had turned into a forward-looking answer.
Most SQL Server monitoring is built to tell you about right now: current disk usage, current database size, current table row counts. That’s necessary, but it answers the wrong question when leadership is asking about next quarter’s budget. “We’re at 62% disk utilization” is a snapshot. “At the current growth rate, we’ll hit 85% in roughly six weeks” is a plan.
SQL Diagnostic Manager already collects the underlying data needed to make that shift — disk usage, database size, and table size, tracked continuously over time across every monitored instance. Forecasting doesn’t require a new agent, a new data source, or a new collection job. It’s a matter of pointing the reporting engine at data that has been accumulating the entire time and asking it to project forward.
The forecasting capability in SQL DM isn’t a single report — it works at three levels, so a team can zoom in from a broad storage view down to the specific table driving growth:
Together, these three views answer the question leadership actually asks in a different order than most teams expect: not “how much storage do we have,” but “where is it going, how fast, and which specific database or table is responsible.”
SQL DM’s forecast reports support two forecasting types, and choosing the right one matters more than it might first appear. Linear forecasting follows the existing trend in the data and extends it forward in a straight line — a reasonable default for workloads that grow at a steady, predictable pace, like a transactional database adding a consistent volume of records each month.
Exponential forecasting, by contrast, is more aggressive: it assumes the rate of growth itself is accelerating, not just the volume. That matters for workloads where growth compounds — a logging table that grows faster as an application scales its user base, or a reporting database that expands as more business units get onboarded. Choosing exponential when growth is genuinely accelerating avoids the common mistake of a linear forecast that looks comfortable right up until it isn’t.
The practical guidance most teams land on: start with the largest available window of historical data and the shortest reasonable forecast horizon, since both choices improve forecast accuracy, and re-run the report periodically rather than treating a single forecast as a permanent answer.
This is where forecasting earns its place as a business tool, not just a technical one. A DBA who already knows their environment well may have an intuitive sense of which databases are growing. Leadership rarely has that intuition, and a budget request based on “I have a feeling we’ll need more storage” tends to get deprioritized against requests that come with a number attached.
A forecast report changes that dynamic. Instead of a general storage concern, a DBA can walk into a budget conversation with a specific, defensible statement: this database is projected to grow by a specific amount over the next quarter, at the current observed rate, and here is the table inside it that is responsible for most of that growth. That is a fundamentally different conversation — it turns an infrastructure request into something backed by data, and for customers who need to justify storage spend or plan ahead for growth, this capability tends to pay for itself the first time it’s used in a budget conversation.
It also reframes the DBA’s role in that conversation. Instead of being the person asking for more resources, the DBA becomes the person who saw it coming and already has a plan — which is a meaningfully stronger position both for the immediate budget ask and for how the team’s judgment gets trusted the next time around.
Getting from “we have this data” to “here’s our capacity plan” doesn’t require a big project. A practical starting workflow:
Storage forecasting is not a capability unique to SQL Diagnostic Manager. Where SQL Diagnostic Manager sets itself apart is in how the data gets there and what it costs to keep it flowing. Several competing platforms are built around ingest-based pricing, where the cost of monitoring — and by extension, forecasting — scales with the volume of data collected.
SQL Diagnostic Manager’s forecasting is calculated directly from the performance and space-usage data the platform already collects agentlessly, at no additional ingest cost, as part of the same monitoring it’s already doing for performance troubleshooting. There’s no separate forecasting tier to buy into and no ingest bill that grows alongside the environment. For teams that are already collecting this data and simply haven’t turned it into a forward-looking report yet, that’s a meaningfully lower bar to start using it than standing up a new forecasting-specific tool.
| Forecasting Can | The DBA Must Determine |
|---|---|
| Project disk, database, and table growth from historical trend | Which volumes, databases, and tables matter most to forecast first |
| Offer Linear or Exponential projections | Which forecast type fits a given workload’s actual growth pattern |
| Flag which specific tables are driving growth | Whether that growth reflects normal usage or something worth investigating |
| Surface a projected timeline to a capacity threshold | How urgently to escalate that timeline into a budget conversation |
| Re-run on demand as new data accumulates | How often to refresh the forecast for a given environment |
Forecasting accelerates the analysis. The DBA still owns the decision.
The next time someone asks how much storage runway you have, the honest, complete answer shouldn’t require a scramble. SQL Diagnostic Manager has been collecting the growth data the whole time — the Disk Space Usage Forecast, Database Growth Forecast, and Table Growth Forecast reports simply turn it into a projection you can act on before a slow-building problem becomes an urgent one. If you haven’t run a forecast report yet, the fastest way to find out what it tells you is to run one against your busiest database this week.
Does forecasting require any new data collection or agents?
No. SQL Diagnostic Manager forecasts growth using disk, database, and table size data it is already collecting agentlessly. Running a forecast report is a configuration step, not a new deployment.
How far in advance can I forecast?
The forecast horizon is configurable, but accuracy improves with a larger window of historical data and a shorter forecast period — most teams get the most reliable results forecasting a few weeks to a couple of months out.
What’s the difference between Linear and Exponential forecasting?
Linear forecasting extends the existing trend forward in a straight line, suited to steady, predictable growth. Exponential forecasting assumes the growth rate itself is accelerating, and tends to be more accurate when growth is compounding rather than constant.
Can I forecast a specific table instead of a whole database?
Yes. The Table Growth Forecast report drills down to individual tables, which is useful when a Database Growth Forecast shows a database expanding quickly and you need to know exactly what’s driving it.
Is this the same as SolarWinds’ Storage Forecasting?
It addresses a similar need — projecting future growth from historical data — but SQL DM calculates it from data already collected agentlessly at no additional ingest cost, rather than a separately priced, ingest-based analytics layer.
Forecasting turns a reactive conversation into a proactive one. If the data has been sitting in SQL Diagnostic Manager the whole time, the only thing left to do is look.
Knowledge Base
Brandon Adams - 22 June
Knowledge Base
Brandon Adams - 20 June
Knowledge Base
Brandon Adams - 19 June
Knowledge Base
Brandon Adams - 18 June
Contact our sales team to get a personalized demo of our database management software for SQL Server!
