Capacity forecasting gets discussed constantly in SQL Server monitoring circles, and it is usually framed as a feature-list checkbox rather than an explanation of how...
Capacity forecasting gets discussed constantly in SQL Server monitoring circles, and it is usually framed as a feature-list checkbox rather than an explanation of how it actually works, or what it takes to trust the result. The IDERA tutorial Capacity Planning with SQL Diagnostic Manager for SQL Server walks through the configuration and reporting inside SQL Diagnostic Manager, and it is the basis for the workflow below.
SQL Server capacity forecasting projects future disk space, database size, or table size by extending an observed historical growth trend forward in time, using either a Linear model (a steady, straight-line trend) or an Exponential model (an accelerating trend). SQL Diagnostic Manager calculates these forecasts directly from performance and space-usage data it is already collecting, with no separate data-ingestion step required.
Capacity Planning with SQL Diagnostic Manager for SQL Server
Capacity forecasting is the practice of projecting future resource consumption — disk space, database size, or table size — based on how that resource has actually grown over time, rather than a fixed estimate or a manual spreadsheet calculation. In SQL Diagnostic Manager, this is delivered through three related reports: the Disk Space Usage Forecast, the Database Growth Forecast, and the Table Growth Forecast.
Each report answers a related but distinct question. The Disk Space Usage Forecast answers “how much free space will this volume have left, and when will it run low?” The Database Growth Forecast answers “which databases are growing fastest, and by how much?” The Table Growth Forecast answers “which specific tables inside that database are responsible for the growth?”
SQL DM builds each forecast from the historical disk, database, and table size data it is already collecting continuously across every monitored instance. There is no separate collection step to configure and no additional ingest pipeline to stand up — the forecast report simply reads the existing history and projects it forward using the forecasting type selected.
For more accurate results, the guidance is straightforward: select the largest available window of historical data, and forecast the shortest reasonable period into the future. A forecast built on six months of history projecting three months forward will generally be more reliable than one built on two weeks of history projecting a year out.
Linear forecasting follows the existing trend in the data and extends it forward in a straight line by the number of forecast units selected. It is a reasonable default for workloads that grow at a steady, predictable pace — a transactional table adding a roughly consistent number of rows each week, for example.
Exponential forecasting, sometimes described as the more aggressive option, assumes the rate of growth is itself increasing rather than staying flat. This tends to produce a more accurate forecast when growth is genuinely accelerating — a logging table growing faster as an application’s user base scales, or a reporting database expanding as more business units get onboarded. Picking Linear for a workload that is actually accelerating will understate how soon action is needed; picking Exponential for a workload that is genuinely steady will overstate urgency. Reviewing the shape of the historical trend before choosing is worth the extra minute.
Picture two databases on the same instance. Database A supports a mature, stable internal application and has added roughly the same amount of data every month for the past year — a textbook case for Linear forecasting. Database B supports a newly launched customer-facing feature, and its growth rate has been increasing each month as adoption climbs — a case where Exponential forecasting will track reality far more closely than a straight-line projection.
Applying Linear forecasting to Database B would produce a comfortable-looking projection that consistently underestimates how soon it will need more room, precisely because it assumes this month’s growth rate will hold steady rather than continuing to climb. Running both a Linear and an Exponential forecast side by side, and comparing which one the actual trend more closely resembles, is a useful first check before committing to a single number in a report.
Storage problems rarely happen instantly. A volume that fills up this month was very likely trending in that direction for weeks or months beforehand — the data existed, but nobody had turned it into a forward-looking view. Most day-to-day monitoring is built to answer “what’s happening right now,” which is necessary but insufficient for a question like “do we need to budget for more storage next quarter.”
The gap is rarely a data problem. SQL Diagnostic Manager has typically been collecting the underlying disk, database, and table size history the entire time a customer has been using it. The gap is that nobody ran the forecast report, because the capability is easy to overlook when day-to-day monitoring is focused on immediate performance issues rather than longer-range planning.
SolarWinds Database Performance Analyzer markets Storage Forecasting as one of its headline AI-driven capabilities, and it is worth a direct, fair comparison, since it is the most similar capability offered by a competing SQL Server monitoring platform.
The core forecasting concept is similar in both platforms: project future storage needs from historical growth data. The practical difference is in the pricing model underneath it. Several competing platforms, including tools built on ingest-based pricing, charge based on the volume of data collected and retained — which means the cost of monitoring, and by extension the cost of the data feeding a forecast, can scale up as an environment grows. SQL Diagnostic Manager calculates its forecasts from performance and space-usage data collected agentlessly as part of standard monitoring, at no additional ingest cost, so running a Disk Space Usage Forecast, a Database Growth Forecast, or a Table Growth Forecast doesn’t carry an incremental data-volume charge.
| Dimension | Manual / Spreadsheet Tracking | SQL DM Growth Forecasting |
|---|---|---|
| Data source | Manually exported historical snapshots | Continuously collected disk, database, and table size data |
| Update effort | Requires a person to re-pull and recalculate | Re-run the report on demand from existing history |
| Forecast model | Usually a single straight-line assumption | Linear or Exponential, selectable per report |
| Granularity | Typically whole-volume or whole-database only | Drills down to disk, database, and individual table level |
| Additional ingest cost | None, but high manual effort | None — calculated from data already collected agentlessly |
| Best suited for | One-off, ad hoc capacity checks | Recurring capacity planning and budget conversations |
Does forecasting require a separate license or add-on?
No. Disk Space Usage Forecast, Database Growth Forecast, and Table Growth Forecast reports are part of the existing SQL Diagnostic Manager license and use data the platform is already collecting.
How much historical data do I need before a forecast is reliable?
There is no hard minimum, but forecast accuracy improves with a larger window of historical data. The general guidance is to use the largest available history and the shortest reasonable forecast period.
Can I forecast at the table level instead of the whole database?
Yes. The Table Growth Forecast report drills down to individual tables, which is useful when a Database Growth Forecast shows fast overall growth and you need to identify the specific cause.
Is Exponential forecasting always more accurate than Linear?
No. Exponential forecasting is more accurate when growth is genuinely accelerating. For workloads with a steady, consistent growth rate, Linear forecasting is typically the better fit.
How is this different from SolarWinds’ Storage Forecasting?
Both project future storage needs from historical data. SQL DM calculates its forecasts from data already collected agentlessly at no additional ingest cost, rather than a separately priced, ingest-based analytics layer.
Can forecasting replace a DBA’s judgment about when to act?
No. Forecasting projects a trend and estimates a timeline; deciding how urgently to act, whether the growth reflects normal usage, and how to prioritize a storage request still requires the DBA’s own judgment.
Static, right-now dashboards and forward-looking growth forecasts are not competing approaches — they answer different questions. The practical path is to keep using day-to-day monitoring for immediate performance issues, and add a recurring forecast review for the capacity and budget conversations that depend on knowing what’s coming, not just what’s happening now.
SQL Diagnostic Manager for SQL Server
SQL Diagnostic Manager for SQL Server
Brandon Adams - 30 June
SQL Diagnostic Manager for SQL Server
Brandon Adams - 22 June
SQL Diagnostic Manager for SQL Server
Brandon Adams - 20 June
SQL Diagnostic Manager for SQL Server
Brandon Adams - 19 June
SQL Diagnostic Manager for SQL Server
Brandon Adams - 18 June
Contact our sales team to get a personalized demo of our database management software for SQL Server!
