Attachments contribution to overall instance Storage

[creativecookie]

I have been looking at the Storage consumption on our instances and I realize that the biggest table in the instance is the sys_attachment_doc table which is nearly about 21% of the total production storage for us.

The local database storage for attachments is a very expensive storage to consume. So, I am wondering if there are options to

1. Compress files before storing in the database before storing
2. Store the attachments outside the instance in a cheaper storage location like an AWS S3 bucket and put a reference link to the attachment.

[Maik Skoddow]

Basically ServiceNow is not a document management system and due to the restricted database size not suitable for storing many/large attachments. Therefore it is the responsibility of a system admin to monitor the attachment growth and maintain the sys_attachment table. Please check the following posts which provide many tips and tricks for this topic: https://www.servicenow.com/community/forums/searchpage/tab/message?q=instance%20footprint%20attachme... 

1) ServiceNow already tries to compress the data before storing it

2) Go to https://store.servicenow.com/sn_appstore_store.do#!/store/home . You will find there many solutions and spokes to connect to external document storages.

[Jiri Nadvornik]

We've worked with a number of customers facing exactly this issue. In fact, having sys_attachment_doc consume 40–70% of the database is quite common, so your 21% is actually lower than what we typically see.

We explored both approaches you mentioned:

1. The compression provides only limited savings in practice. Most of the storage growth usually comes from PDFs, images, videos, and Office documents or other text formats are usually already compressed.
2. This is the direction we ultimately took. We built a solution that moves only the sys_attachment_doc data to external storage (Azure Blob Storage, AWS S3, or Google Cloud Storage), while keeping the sys_attachment records in ServiceNow. From the user's perspective, attachments continue to work exactly as before—they can preview, download, and interact with them without any change in the UI. 

There are other ways to reduce attachment storage (archiving, deletion rules, etc.), but many approaches that move attachments outside ServiceNow require users to access a separate system or lose native functionality. Our goal was to avoid those compromises and make the offloading completely transparent.

If you're still evaluating this approach, I'd be happy to share our experience or give you a quick demo of how it works in practice. You can also check out the product SnowMirror Drive on our website.