Quick Scan Report – SQL Express Approaching File Limitation

What this check looks for

On Express edition only, the size of each online database’s data files against the edition’s limit. The check fires as a database approaches it, and a companion check reports the same condition measured against the version specific ceiling.

The limit depends on the version:

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, which measures the same limit against the version specific ceiling: it warns at 9 GB on SQL Server 2022 and earlier, and at 45 GB on SQL Server 2025 and later.

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.[database_id] > 4       -- skip the system 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:

SELECT [name],
       CAST([size] * 8.0 / 1024 AS DECIMAL(12,1))                            AS [size_mb],
       CAST(FILEPROPERTY([name], 'SpaceUsed') * 8.0 / 1024 AS DECIMAL(12,1)) AS [used_mb]
  FROM sys.database_files WITH (NOLOCK)
 WHERE [type] = 0;

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:

1. 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.
2. 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.
3. 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.
4. 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

Related checks

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.