Optimizing TFS Database Storage: Managing Documents, Build Packages, and Test Artifacts

The article begins by describing the problem of rapid TFS database growth caused by large binary files such as documents, source code, build packages, and test results, which can increase storage costs for enterprises as project size expands.

Typical large‑size items include work‑item attachments, documentation, source files, compiled build packages, and test artifacts. The focus is on managing documentation, source code, build packages, and test data.

Document Management

Storing many non‑text documents directly in the version control repository is discouraged. Instead, use SharePoint, a dedicated document server, or TFS Wiki (Markdown) for technical documentation. For binary‑heavy documents, TFVC is preferred over Git, or use Git LFS with the appropriate client extension.

Source Code Storage

Source code itself is usually lightweight, but compiled binaries and third‑party packages can consume significant space. Recommended practices include cleaning unnecessary binaries, using a private package manager, or storing large packages on a shared file server.

Build Package Size Settings

Set a maximum file size for Git repositories (e.g., 100 MB) to prevent oversized binaries.

Build Artifact Storage Options

Two main options exist: storing artifacts in the TFS database (simple but can bloat the DB) or using a Windows file share (requires a separate server and works only with Windows agents). For cross‑platform pipelines, FTP or SSH can be used.

For larger teams, an artifact repository (e.g., NuGet, npm, Maven, Gradle, or a custom repository) is recommended to manage both packages and build outputs.

Test Management Data

Test runs, screenshots, and recordings are stored as binary blobs and can quickly fill the database. Retention policies should be configured, and tools like Tcmpt can clean up old test data.

TFS Data Size Analysis

To identify the biggest space consumers, the article provides several SQL scripts. Example to list database sizes:

use master
select DB_NAME(database_id) AS DBName, (size/128) SizeInMB
FROM sys.master_files
where type=0 and substring(db_name(database_id),1,4)='Tfs_'
and DB_NAME(database_id)<> 'Tfs_Configuration' order by size desc

Another script groups file sizes by owner type, revealing that FileContainer data occupies most space.

SELECT Owner =
CASE
WHEN OwnerId = 0 THEN 'Generic'
WHEN OwnerId = 1 THEN 'VersionControl'
WHEN OwnerId = 2 THEN 'WorkItemTracking'
WHEN OwnerId = 3 THEN 'TeamBuild'
WHEN OwnerId = 4 THEN 'TeamTest'
WHEN OwnerId = 5 THEN 'Servicing'
WHEN OwnerId = 6 THEN 'UnitTest'
WHEN OwnerId = 7 THEN 'WebAccess'
WHEN OwnerId = 8 THEN 'ProcessTemplate'
WHEN OwnerId = 9 THEN 'StrongBox'
WHEN OwnerId = 10 THEN 'FileContainer'
WHEN OwnerId = 11 THEN 'CodeSense'
WHEN OwnerId = 12 THEN 'Profile'
WHEN OwnerId = 13 THEN 'Aad'
WHEN OwnerId = 14 THEN 'Gallery'
WHEN OwnerId = 15 THEN 'BlobStore'
WHEN OwnerId = 255 THEN 'PendingDeletion'
END,
SUM(CompressedLength) / 1024.0 / 1024.0 AS BlobSizeInMB
FROM tbl_FileReference AS r
JOIN tbl_FileMetadata AS m
ON r.ResourceId = m.ResourceId
AND r.PartitionId = m.PartitionId
WHERE r.PartitionId = 1
GROUP BY OwnerId
ORDER BY 2 DESC

Further analysis of tbl_Container and monthly growth trends helps pinpoint specific tables (e.g., tbl_Content ) that need cleanup.

Conclusion

The article summarizes that using an artifact repository for binaries, adopting a proper document management strategy, and configuring retention policies are key to controlling TFS database size, especially as teams and projects scale.