Onpremise PostgreSQL database size

💬 Self Hosted Retool
,
1

Hello

We have an onpremise infrastructure and we are a little bit worried about the size of the PostgreSQL database that retools use for its internall processes. Why is so big? Is there any way to optimize the space?

postgres=# SELECT

pg_database.datname AS database,

pg_size_pretty(pg_database_size(pg_database.datname)) AS size

FROM pg_database

WHERE datname = 'retooldb';

database    | size

----------------+-------

retooldb | 38 GB

(1 row)

Thanks!

3

Most likely the top 2 tables eat most of the spaces:

page_saves & audit_trail_events

I believe currently Retool self-host neither have data retention policy nor have a handy tool to backup the old data….so those tables will just grow bigger and bigger overtime. Especially, if i understand correctly, page_saves saves the full code of the app on every change / release, so it will consume disk space aggresively.

I have the same concern perviously on this post:

4

Thaks zelterNN for the quick reply, so it is okay if I delete audit_trail_events table, did you try before? I dont want to break anything

This is the actual size of both tables

schema_name | table_name | total_size
-------------+--------------------+------------
public | audit_trail_events | 6760 MB
public | page_saves | 31 GB
(2 rows)

5

I’d redirect this question to Retool team…..as I haven’t had the opportunity to trim these tables myself for now :rofl:

My understanding:

  • audit_trail_events, functions more as an endpoints table and should be safe to trim directly without major issues.
  • page_saves, on the other hand, is intertwined with other tables—such as tags—and modifying it could have broader downstream impacts.
6

Hello @Jorge,

@zelterNN Is correct!

The the audit_trail_events table is safe to trim as needed.

As Linda mentioned in the thread that Zelter linked, she is correct.

The page_save holds all of every single time an app saves and can grow really big really fast.

If you clear it out, you will not be able to go back in a previous save.

Thus, the best option for trimming is to make a new release version of your app. Then when you join with the tags table, you can benchmark all the changes based on which tag(app version) the change corresponds to.

Then you can pick how far back in terms of app version you are ok with parting ways from and can then do the DB surgery to delete the save rows that are prior to the app version you want to keep!

Be careful with DB surgery as we recommend having a backup just in case anything unexpected happens so you can avoid the worse case scenario of losing a save or version of you app that you want to keep.

Hope this helps :saluting_face: