Quick Scan Report – SQL Express Approaching File Limitation
What this check looks for
On Express edition only, the size of each online, read-write database’s data files against the edition’s limit. The check fires when the data files total more than 1 GB under the limit (over 9 GB on SQL Server 2022 and earlier, over 49 GB on SQL Server 2025 and later) and the files have less than 1,000 MB of free space left inside them. A database with that much headroom in its files is not reported.
The limit depends on the version:
| Version | Data file limit per database |
|---|---|
| SQL Server 2025 and later | 50 GB |
| SQL Server 2008 R2 through 2022 | 10 GB |
| SQL Server 2005 and 2008 | 4 GB |
The limit applies to the data files of a single database, added together. Adding a second data file does not get you past it. The transaction log does not count towards it.
This page also covers issue 206, SQL Express nearing file size capacity (vanity URL https://DatabaseHealth.com/SQLExpressFileSize), a second check on the same limit. It measures the space actually used inside the data files rather than the file size, and it warns when that exceeds 9,000 MB on SQL Server 2022 and earlier, and 45,000 MB on SQL Server 2025 and later. Both checks are High severity and report a Warning finding per database, and both link to the Databases By Size report.
Why it matters
This is a hard stop with no degradation before it. The database works normally until the data files reach the limit, and then:
Could not allocate space for object '...' in database '...'
because the 'PRIMARY' filegroup is full.
That is error 1105, the same error you get from a full disk, and that resemblance is what makes it hard to diagnose. The first response is to check the drive, find hundreds of gigabytes free, and conclude the error must mean something else. It does not. The limit is enforced by the edition, not by the storage.
Inserts and updates that need new space fail. Reads keep working, which means the application partly works, which is usually reported as “the application is behaving strangely” rather than as an outage.
The second reason this matters: it almost always arrives unannounced on a server nobody owns. Express is chosen for a small application, installed by a vendor, and forgotten. It has no Agent, so it has no scheduled backups, no maintenance, and no alerting. There is no DBA watching it because nobody knew it was there.
How to confirm it yourself
SELECT DB_NAME(mf.[database_id]) AS [database_name],
CAST(SUM(mf.[size]) * 8.0 / 1024 / 1024 AS DECIMAL(10,2)) AS [data_gb],
COUNT(*) AS [data_files]
FROM sys.master_files AS mf WITH (NOLOCK)
INNER JOIN sys.databases AS d WITH (NOLOCK)
ON d.[database_id] = mf.[database_id]
WHERE mf.[type] = 0 -- data files only, the log does not count
AND d.[state] = 0 -- online
AND d.[is_read_only] = 0 -- the check skips read-only databases
GROUP BY mf.[database_id]
ORDER BY [data_gb] DESC;
Confirm the edition and version, which set the limit:
SELECT SERVERPROPERTY('Edition') AS [edition],
SERVERPROPERTY('ProductVersion') AS [version],
SERVERPROPERTY('EngineEdition') AS [engine_edition];
And how much of the space in the file is actually used, which is the difference between having a problem now and having one soon. Issue 88 fires when the total size is within 1 GB of the limit and free space is under 1,000 MB, and issue 206 fires when the used total passes 9,000 MB (45,000 MB on 2025 and later):
SELECT CAST(SUM([size]) * 8.0 / 1024 AS DECIMAL(12,1)) AS [size_mb],
CAST(SUM(FILEPROPERTY([name], 'SpaceUsed')) * 8.0 / 1024 AS DECIMAL(12,1)) AS [used_mb],
CAST(SUM([size] - FILEPROPERTY([name], 'SpaceUsed')) * 8.0 / 1024 AS DECIMAL(12,1)) AS [free_mb]
FROM sys.database_files WITH (NOLOCK)
WHERE [type] = 0;
Run it in each database.
How to fix it
There are only two real answers: make the data smaller, or stop using Express.
Buy time, in the order that costs least:
- Find out what is actually large. Very often it is one table, and very often it is an audit, log or history table that nobody ever set a retention policy on. The Table Sizes report answers this in one look.
- Archive or delete what you do not need. Deleting rows frees space inside the file, and this is the one situation where shrinking the data file afterwards is genuinely appropriate, because the file size is the thing being measured.
- Rebuild the indexes. On a database that has never had maintenance, and Express databases usually have not, reclaiming the space wasted by fragmentation can recover a surprising amount.
- Enable data compression, if the version allows it. Row and page compression became available in all editions from SQL Server 2016 SP1, which includes Express, and on the right table it is a large win.
Then solve it properly. Every option above buys months, not years, and the database is still growing.
- Upgrade to Standard edition. The real fix, and the cost is the licence.
- On SQL Server 2025 or later, Express itself allows 50 GB, so upgrading the version of Express raises the ceiling substantially at no licence cost.
- Split the database, if it holds separable things. Each database gets its own limit. This is a workaround and it makes the application more complicated, but it is legitimate where there genuinely are two datasets.
- Move the history somewhere else. If the size is an audit or archive table, that table does not have to live in the operational database.
While you are there, remember Express has no Agent. Check that something is backing this database up, because in the situation this check describes the thing most likely to be missing is a backup.
How long it takes
About four hours to investigate and buy time. Moving to another edition is a project with a licence decision in it.
Related reports
| Report | Why you would go there |
|---|---|
| Table Sizes | Which table is using the space, which is usually one table. |
| Large Tables | The same question ranked by size. |
| Databases By Size | Every database against the limit. |
| File Utilization | How much of the allocated file is genuinely used. |
| Index Fragmentation | Space recoverable by rebuilding. |
| Table Space Breakdown | Data against index against unused, for one table. |
| Backup Status | Whether anything is backing this up at all. |
Related checks
| Check | |
|---|---|
| SQL Express nearing file size capacity | The same limit, measured on used space rather than file size. |
| SQL Express core limit | The other Express limit, on processors. |
| SQL Server Express edition | Express in use at all, which is worth knowing. |
| SQL Agent Not Running | Express has no Agent, so nothing is scheduled here. |
| No recent backups | The consequence of that, which is very common on Express. |
Frequently asked questions
Can I add another data file to get past the limit? No. The limit is the total of the data files in the database, so a second file changes nothing.
Does the transaction log count? No. The log can be any size the disk allows.
Is it per database or per instance? Per database. An Express instance can host several databases, each up to the limit.
We are on SQL Server 2025 Express, so we have 50 GB? Yes, and that is a genuine reprieve. Upgrading an older Express instance to 2025 raises the ceiling from 10 GB to 50 GB with no licence cost, which is often the cheapest answer available.
Nothing has failed yet. The check reports the approach rather than the arrival, on purpose. There is no warning at the moment it is reached.