# Quick growth of piece\_expiration.db

**URL:** <https://forum.storj.io/t/quick-growth-of-piece-expiration-db/24965>\
**Category:** troubleshooting\
**Tags:** database\
**Created:** [January 15, 2024, 5:58pm UTC](https://forum.storj.io/t/quick-growth-of-piece-expiration-db/24965 "2024-01-15T17:58:17Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [January 19, 2024, 7:18am UTC](https://forum.storj.io/t/quick-growth-of-piece-expiration-db/24965/16 "2024-01-19T07:18:15Z")

</div>

You can vacuum them the usual way for SQLite:

1. Stop and remove the container (or stop the service in case of Windows/Linux GUI)
2. Run the command

> [@Vacuum databases in a ramdisk to reduce downtime](https://forum.storj.io/t/vacuum-databases-in-a-ramdisk-to-reduce-downtime/7066):
>
> I have a bunch of nodes and tested runtime of vacuuming the databases in-place against copying them to a ramdisk, vacuuming them there, and moving them back to the disk. The results are quite impressive. The orders database takes the overwhelming majority of the time so I’m including its size before and after. Both nodes run on the same host (two Docker containers). They run on different HDDs; both are exactly the same model. Node 1: 300MB orders database. Vacuuming all databases in-place t…

However

> [@Database is locked. What is the reason? What is the possible solution?](https://forum.storj.io/t/database-is-locked-what-is-the-reason-what-is-the-possible-solution/6806/30):
>
> Why do we have to call vacuum? That shouldn’t be needed. Autovacuum should also not be needed.

I think you should not fix what’s not broken.

---

_[View the full topic](https://forum.storj.io/t/quick-growth-of-piece-expiration-db/24965)._