# Anormally large PostgreSQL Database size

**URL:** <https://community.sonarsource.com/t/anormally-large-postgresql-database-size/74268>\
**Category:** SonarQube Server / Community Build\
**Tags:** housekeeping, postgres, database\
**Created:** [October 10, 2022, 11:09am UTC](https://community.sonarsource.com/t/anormally-large-postgresql-database-size/74268 "2022-10-10T11:09:29Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![idles\_23](https://avatars.discourse-cdn.com/v4/letter/i/5f9b8f/32.png) [@idles\_23](https://community.sonarsource.com/u/idles_23)\
**Post date:** [October 10, 2022, 11:09am UTC](https://community.sonarsource.com/t/anormally-large-postgresql-database-size/74268/1 "2022-10-10T11:09:29Z")

</div>

Hi everyone,

We have recently known that our Sonarqube LTS database, placed in an AWS RDS instance and with PostgreSQL 12 core, has a size of nearly 190 Gb:

If we type in Pgadmin data query:

_SELECT pg\_size\_pretty(pg\_database\_size(‘\<name\_of\_sonarqubeDB’));_

the result is 190 Gb and if we look into the tables size, the table “file\_sources” has a size of 52 Gb.

As a workaround, we have deleted manually all the PRs and branches analysis previous to a certain date, and we have manually deleted all the “file\_sources” table rows previous to a certain date regarding to the condition above.

After that, we have looked that the size of the database and the “file\_sources” table remains the same.  
The DBCleaner parameters in our Sonarqube instance are set by default and works well.

¿How can we cleanup the size of the database?

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\
**Post date:** [October 11, 2022, 12:01pm UTC](https://community.sonarsource.com/t/anormally-large-postgresql-database-size/74268/2 "2022-10-11T12:01:56Z")

</div>

Hey there.

> [@idles\_23](#):
>
> As a workaround, we have deleted manually all the PRs and branches analysis previous to a certain date, and we have manually deleted all the “file\_sources” table rows previous to a certain date regarding to the condition above.

You **cannot** manually update the SonarQube database. You should consider that your database is corrupted and restore to a version that hasn’t been manually altered.

Do you regularly run a `VACUUM` on your database to reclaim freed space?

---

<div class="post-metadata">

**Author:** ![idles\_23](https://avatars.discourse-cdn.com/v4/letter/i/5f9b8f/32.png) [@idles\_23](https://community.sonarsource.com/u/idles_23)\
**Post date:** [October 11, 2022, 1:01pm UTC](https://community.sonarsource.com/t/anormally-large-postgresql-database-size/74268/3 "2022-10-11T13:01:39Z")

</div>

Hi Colin and thanks in advance for your quick answer,

Theorically, in the pgAdmin database properties the AUTOVACUUM property is set to 1, so theorically the AUTOVACUUM operations must be done automatically.  
Here are the autovacuum properties of our Sonarqube Postgre database:

| autovacuum | on |
| --- | --- |
| autovacuum\_analyze\_scale\_factor | 0.05 |
| autovacuum\_analyze\_threshold | 50 |
| autovacuum\_freeze\_max\_age | 200000000 |
| autovacuum\_max\_workers | 3 |
| autovacuum\_multixact\_freeze\_max\_age | 400000000 |
| autovacuum\_naptime | 15 |
| autovacuum\_vacuum\_cost\_delay | 2 |
| autovacuum\_vacuum\_cost\_limit | 200 |
| autovacuum\_vacuum\_scale\_factor | 0.1 |
| autovacuum\_vacuum\_threshold | 50 |
| autovacuum\_work\_mem | -1 |

We don’t know if this properties are OK or not, but are the default properties I think.  
Regarding to VACUUM operations, we don’t know exactly if it should be done a VACUUM FULL for all the database or only a VACUUM and what kind of result must throw this command.

Finally, our database is not corrupted at all, so we are sure of this. Neverthless, we’ll be more careful to not update or delete anything in the database directly.

Best regards.