It makes sense: SQL Server uses the concepts of “before image” and “after image”. The “after image” should contain the varbinary(max) column content after the insert/update statement. If the transaction succeeds, the “after image” becomes the current data. The “before image” is recorded in a special table, named “tombstone”; a garbage collector process will clear this image.

This GC process does not execute immediately after the last transaction commit.

The current published information is: “a FS garbage collection executes at a CHECKPOINT”.

There are some events that automatically trigger the GC, but they occur only in special contexts (log file active portion exceeds a certain size, log file is over 70% full and the database is in log-truncate mode) that do not appear during standard operations.

Conclusion : if you want to explicitly trigger a garbage collection, issue a CHECKPOINT statement (, backup  the database or stop SQL Server. There is a chance this will not delete all tombstoned FS entries (see, so be prepared to have some unusable disk space when working with FS storage, especially if you often update the varbinary(max) columns.