# Database cleanup

**URL:** <https://anchorecommunity.discourse.group/t/database-cleanup/477>\
**Category:** General\
**Created:** [June 24, 2025, 6:39pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477 "2025-06-24T18:39:18Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![rdstoddard](https://avatars.discourse-cdn.com/v4/letter/r/f05b48/32.png) [@rdstoddard](https://anchorecommunity.discourse.group/u/rdstoddard)\
**Post date:** [June 24, 2025, 6:39pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/1 "2025-06-24T18:39:18Z")

</div>

I have inherited an anchore installation that has been in place for a year, and the DB directory has grown to roughly 90GB in size. There is no archival storage defined and no option for archiving older scanning artifacts to object storage. Is there a guide available for manually deleting old artifacts from the db to clear storage.

---

<div class="post-metadata">

**Author:** ![Greg\_Nyahay](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/greg_nyahay/32/321_2.png) [@Greg\_Nyahay](https://anchorecommunity.discourse.group/u/Greg_Nyahay)\
**Post date:** [June 24, 2025, 8:25pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/2 "2025-06-24T20:25:19Z")

</div>

Greetings!

We support configuring an object store and also provide a migration path, see the following:

- [Object Storage | Anchore Enterprise Product Documentation](https://docs.anchore.com/current/docs/configuration/storage/object_store/)

We have options for configuring image archival as well (once you have configured an object store for analysis archive):

- [Using the Analysis Archive | Anchore Enterprise Product Documentation](https://docs.anchore.com/current/docs/configuration/analysis_archive/)

With or without an object store we have the ability to define an image lifecycle to expire data after certain criteria:

- [Artifact Lifecycle Policies | Anchore Enterprise Product Documentation](https://docs.anchore.com/current/docs/configuration/artifact_lifecycle_policy/)

Make sure you have enable\_data\_egress set to true per the following:

- [Reports | Anchore Enterprise Product Documentation](https://docs.anchore.com/current/docs/configuration/reports/)

If you can tell me what version you are on and what versions you were on previously (deployment\_history table) I can provide some additional cleanup options.

Lastly, we, Anchore Support, are here for you so do not hesitate to reach out to us via [anchore.zendesk.com](http://anchore.zendesk.com)!

---

<div class="post-metadata">

**Author:** ![rdstoddard](https://avatars.discourse-cdn.com/v4/letter/r/f05b48/32.png) [@rdstoddard](https://anchorecommunity.discourse.group/u/rdstoddard)\
**Post date:** [June 25, 2025, 2:46pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/3 "2025-06-25T14:46:00Z")

</div>

Currently we are running on 5.18.0. Will get the version history for you. I’ve updated the following settings in the docker compose file and redeployed:

```
  - ANCHORE_ENTERPRISE_REPORTS_ENABLE_DATA_EGRESS=true
  - ANCHORE_ENTERPRISE_REPORTS_DATA_EGRESS_WINDOW=0

```

for both the reports and reports\_worker services. I previously had configured a lifecycle policy to delete images after 30 days:

[root@RH8-Harbor-Anchor-xfer anchore]# ./anchorectl system artifact-lifecycle-policy list  
✔ Fetched artifact-lifecycle-policies  
Items:

- action: delete  
createdAt: “2025-01-29T17:01:48Z”  
description: “”  
enabled: true  
name: Test  
policyConditions:
  - artifactType: image  
daysSinceAnalyzed: 30  
evenIfExistsInRuntimeInventory: true  
includeBaseImages: true  
version: 1  
updatedAt: “2025-01-29T17:01:48Z”  
uuid: 317a1344-306b-4b98-b074-3ef2e7cb1bc1

---

<div class="post-metadata">

**Author:** ![rdstoddard](https://avatars.discourse-cdn.com/v4/letter/r/f05b48/32.png) [@rdstoddard](https://anchorecommunity.discourse.group/u/rdstoddard)\
**Post date:** [June 25, 2025, 3:11pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/4 "2025-06-25T15:11:08Z")

</div>

postgres=# select \* from deployment\_history;  
upgrade\_id | from\_database\_version | to\_database\_version | from\_service\_version | to\_service\_version | outcome | db\_upgrade\_duration | created\_at  
--------------------------------------±----------------------±--------------------±---------------------±-------------------±--------±--------------------±---------------------------  
2af6efb9-cb76-44ca-9c2a-3837506eeb4c | | 560 | | 5.6.0 | success | 0 | 2024-06-20 22:13:28.489765  
6153d019-fa4b-4ab0-9add-7af04831f288 | 560 | 570 | 5.6.0 | 5.7.0 | success | 4.940665245056152 | 2024-07-25 11:35:32.332782  
4ebe6190-aafe-4a56-ae0d-85b2edcb2d1b | 570 | 580 | 5.7.0 | 5.8.1 | success | 0.7599983215332031 | 2024-08-22 17:32:41.701066  
1c438ada-df36-4e99-a8fe-fedc67119c0b | 580 | 5100 | 5.8.1 | 5.10.0 | success | 0.8989436626434326 | 2024-10-08 15:15:50.952466  
6711331e-9fa6-430a-8306-68a9d4ad69cb | 5100 | 5110 | 5.10.0 | 5.11.0 | success | 1.396428108215332 | 2024-11-04 19:20:42.032794  
ec95b297-787b-4fd4-a0db-dcf4cad641ef | 5110 | 5120 | 5.11.0 | 5.12.0 | success | 0.9373011589050293 | 2024-12-05 20:33:35.432666  
06ad8e0a-7900-49f9-a059-2dbbd8e273f9 | 5120 | 5130 | 5.12.0 | 5.13.1 | success | 0.9706704616546631 | 2025-01-30 19:11:33.486193  
a7b066c0-5776-42bc-ae49-e598e242828b | 5130 | 5150 | 5.13.1 | 5.15.0 | success | 1.0685653686523438 | 2025-03-04 15:58:06.699248  
b8b4cfeb-93fa-4020-8761-c626a6d67b27 | 5150 | 5170 | 5.15.0 | 5.17.0 | success | 1.4876534938812256 | 2025-05-07 14:14:38.809304  
c6b1f271-62f8-42b1-89dc-86f52c8fca9c | 5170 | 5180 | 5.17.0 | 5.18.0 | success | 2.225947856903076 | 2025-06-03 16:18:05.087039  
(10 rows)

postgres=#

---

<div class="post-metadata">

**Author:** ![Greg\_Nyahay](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/greg_nyahay/32/321_2.png) [@Greg\_Nyahay](https://anchorecommunity.discourse.group/u/Greg_Nyahay)\
**Post date:** [June 27, 2025, 11:45am UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/5 "2025-06-27T11:45:43Z")

</div>

If you are using our Kubernetes Inventory agent - given that you have been on versions prior than v5.11 and now you are v5.17 if the following tables have significant amounts of data in them you may (take a backup first) consider truncating them as they are no longer in use:  
reports\_kubernetes\_containers, reports\_kubernetes\_namespaces, reports\_kubernetes\_nodes, reports\_kubernetes\_pods, reports\_ecs\_containers, reports\_ecs\_services, reports\_ecs\_tasks, reports\_vulns\_by\_ecs\_container, reports\_vulns\_by\_kubernetes\_container, reports\_vulns\_by\_kubernetes\_namespace

If you are using kubernetes inventory it may make sense to set evenIfExistsInRuntimeInventory: false in your lifecycle policy to keep images around that kubernetes inventory actively sees running in your environment.

Lastly… if you do not use the packages gate, verify trigger in policy then you may disable package DB load - Ref: [Gate: packages | Anchore Enterprise Product Documentation](https://docs.anchore.com/current/docs/compliance_management/policy_gates/packages/#:~:text=libssl%2Copenssl-,verify,-Check%20package%20integrity)

Package DB load can be disabled as follows (set on all services or just policyEngine):

```auto
extraEnv:
  - name: ANCHORE_POLICY_ENGINE_ENABLE_PACKAGE_DB_LOAD
    value: "false"

```

Once the setting has been configured the following table may be truncated (take a backup first):

```auto
TRUNCATE image_package_db_entries;

```

You can also look at the size of the image\_package\_db\_entries table ahead of time to gauge the space savings. In addition to the space consumed if you frequently build and scan images with the same image tag it will create a lot of IO on the table via DELETE FROM then INSERT INTO.

Let me know if that helps!

---

<div class="post-metadata">

**Author:** ![rdstoddard](https://avatars.discourse-cdn.com/v4/letter/r/f05b48/32.png) [@rdstoddard](https://anchorecommunity.discourse.group/u/rdstoddard)\
**Post date:** [July 1, 2025, 3:50pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/6 "2025-07-01T15:50:22Z")

</div>

The biggest user of space is object\_store\_documents

public | object\_store\_document\_metadata | table | postgres | permanent | heap | 640 kB |  
public | object\_store\_documents | table | postgres | permanent | heap | 72 GB |  
public | policy\_bundle | table | postgres | permanent | heap | 16 kB  
|

Total size of the DB is 72 GB.

postgres-# \l+  
List of databases  
Name | Owner | Encoding | Collate | Ctype | ICU Locale | Locale Provider | Access privileges | Size | Tablespace | Description  
-----------±---------±---------±-----------±-----------±-----------±----------------±----------------------±--------±-----------±-------------------------------------------  
postgres | postgres | UTF8 | en\_US.utf8 | en\_US.utf8 | | libc | | 78 GB | pg\_default | default administrative connection database  
template0 | postgres | UTF8 | en\_US.utf8 | en\_US.utf8 | | libc | =c/postgres +| 7313 kB | pg\_default | unmodifiable empty database  
| | | | | | | postgres=CTc/postgres | | |  
template1 | postgres | UTF8 | en\_US.utf8 | en\_US.utf8 | | libc | =c/postgres +| 7393 kB | pg\_default | default template for new databases  
| | | | | | | postgres=CTc/postgres | | |  
(3 rows)

---

<div class="post-metadata">

**Author:** ![Greg\_Nyahay](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/greg_nyahay/32/321_2.png) [@Greg\_Nyahay](https://anchorecommunity.discourse.group/u/Greg_Nyahay)\
**Post date:** [July 14, 2025, 3:28pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/7 "2025-07-14T15:28:26Z")

</div>

The object store & object store migration would greatly reduce the size of the object\_store\_documents table although the table would still be used (not nearly as much though):

- [Migrating Data to New Drivers | Anchore Enterprise Product Documentation](https://docs.anchore.com/current/docs/configuration/storage/object_store/migration/)
- [Object Storage | Anchore Enterprise Product Documentation](https://docs.anchore.com/current/docs/configuration/storage/object_store/)

Prior to executing the migration I would suggest ensuring you have a good backup just in case.

I encourage you to leverage our support portal via ZenDesk ([https://support.anchore.com](https://support.anchore.com)) for faster response times in the event you need assistance during this process and also in general for a more customized experience. In this way I am also able to get on a call with you if that is helpful.

---

<div class="post-metadata">

**Author:** ![rdstoddard](https://avatars.discourse-cdn.com/v4/letter/r/f05b48/32.png) [@rdstoddard](https://anchorecommunity.discourse.group/u/rdstoddard)\
**Post date:** [July 23, 2025, 2:51pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/8 "2025-07-23T14:51:17Z")

</div>

postgres=# \c postgres  
You are now connected to database “postgres” as user “postgres”.  
postgres=# SELECT bucket, db\_version, COUNT(\*), SUM(size) FROM object\_store\_document\_metadata GROUP BY bucket, db\_version ORDER BY bucket;  
bucket | db\_version | count | sum  
--------------------------------±-----------±------±----------  
analysis\_data | 5180 | 6 | 171687618  
grypedb | 5180 | 2 | 527144447  
image\_content\_data | 5180 | 6 | 60942603  
manifest\_data | 5180 | 6 | 20906  
parent\_manifest\_data | 5180 | 5 | 20083  
policy\_bundles | 570 | 4 | 35716  
policy\_bundles | 580 | 3 | 20722  
policy\_bundles | 560 | 2 | 11778  
policy-engine-evaluation-cache | 5180 | 6 | 600380  
policy\_evaluations | 5120 | 24 | 668622  
policy\_evaluations | 5110 | 17 | 597226  
policy\_evaluations | 5150 | 18 | 607180  
policy\_evaluations | 5130 | 38 | 1187504  
policy\_evaluations | 5180 | 23 | 1034436  
policy\_evaluations | 5100 | 6 | 181044  
policy\_evaluations | 5170 | 14 | 676209  
policy\_evaluations | 570 | 24 | 561203  
policy\_evaluations | 580 | 58 | 1449777  
syft\_sbom | 5180 | 6 | 91111619  
(19 rows)

postgres=#

---

<div class="post-metadata">

**Author:** ![xusafiyu](https://yyz2.discourse-cdn.com/free1/user_avatar/anchorecommunity.discourse.group/xusafiyu/32/509_2.png) [@xusafiyu](https://anchorecommunity.discourse.group/u/xusafiyu)\
**Post date:** [October 29, 2026, 3:53pm UTC](https://anchorecommunity.discourse.group/t/database-cleanup/477/9 "2026-10-29T15:53:46Z")

</div>

I wouldn’t delete rows directly from the database; Anchore may rely on related records, and manual deletes can leave it inconsistent. First confirm whether the 90 GB is PostgreSQL data or stored analysis artifacts, then use the lifecycle policy Greg linked. If rows are removed but the directory stays large, PostgreSQL may need separate space-reclamation work; the right procedure depends on the database version and deployment.