Sql server used space started steadily increasing at a very quick rate

Hi @Angelo Spaziani

When the used data space is much higher than the actual table size and DBCC SHRINKFILE is not reclaiming space, it is usually due to how Azure SQL Database manages storage internally rather than an issue with the database itself.

In addition to actual data growth, space can remain allocated due to factors such as index fragmentation, ghost records (deleted rows not yet cleaned), or the Persistent Version Store (ADR).

You can follow these steps to identify and reclaim space safely:

Check if space is actually unused

SELECT ``SUM``(size``/128.0``) ``AS`` AllocatedSpaceMB,
SUM``(size``/128.0`` ``-`` ``CAST``(FILEPROPERTY(name, ``'SpaceUsed'``) ``AS`` ``int``)``/128.0``) ``AS`` UnusedSpaceMB
FROM`` sys.database_files ``WHERE`` type_desc ``=`` ``'ROWS'``;

If unused space is high, it may be reclaimable through maintenance operations.

Check space usage per table

SELECT o.name,
SUM``(p.reserved_page_count) ``AS`` reserved_page_count,
SUM``(p.used_page_count) ``AS`` used_page_count
FROM`` sys.dm_db_partition_stats p ``JOIN`` sys.objects o ``ON`` p.object_id ``=`` o.object_id
GROUP`` ``BY`` o.name
ORDER`` ``BY`` reserved_page_count ``DESC``;

Rebuild fragmented indexes
Fragmented indexes can consume additional space. Rebuilding indexes compacts pages and helps release unused internal space. This also removes ghost records.

Check Persistent Version Store (ADR)

SELECT DB_NAME(database_id), persistent_version_store_size_kb
FROM`` sys.dm_tran_persistent_version_store_stats
WHERE`` database_id ``=`` DB_ID();

If large, cleanup can be triggered during a maintenance window:

EXEC sys.sp_persistent_version_cleanup;

Reclaim free space (if required)

After completing the above maintenance steps:

DBCC SHRINKFILE (YourLogicalDataFileName);

Shrink should only be performed after internal cleanup to avoid immediate regrowth.

Higher‑than‑expected used space is typically caused by either workload‑driven growth or internal storage mechanisms such as fragmented indexes, ghost records, or ADR version store. Performing the above maintenance operations can help reclaim unused space and stabilize database size.

Reference:
https://techcommunity.microsoft.com/blog/azuredbsupport/azure-sql-database-or-sql-managed-instance-database-used-data-space-is-much-larg/2162130

Hope this helps, Please let us know if you have any questions and concerns.

After restarting our API service the space immediately was reduced back to 90GB. What could have caused that level of growth related to the API service?