Fider: old installs carry a large `logs` table inside their own database

[LoudLemur]

Posting this because it cost us a nightly backup and I do not think it is documented anywhere.

What happens

Fider has a logger that writes every log entry into a logs table inside its own Postgres database. It is controlled by LOG_SQL, which does not mean "log SQL statements", it means "send logs to SQL". Upstream Fider defaults it to true, and there is no retention, pruning or size cap anywhere in that code path.

Cloudron's Fider package up to and including 2.x also set LOG_LEVEL=DEBUG. Fider traces every SQL statement it executes at DEBUG, and each of those trace lines then becomes another row in that same table. On an install with almost no activity this still produced roughly 24 million rows and 22 GB over thirteen months, in a database where every other table was under 120 kB.

Because Cloudron takes a full pg_dump of the app database on every backup, that table is dumped and uploaded in full every night. Ours reached 27 GB and took over three hours of the nightly run on its own, and one night the run died inside it and everything scheduled behind it kept a stale backup.

Two reasons it can go unnoticed for a long time

1. Package 3.0.0 fixed it, but the changelog does not say so. 3.0.0 (2026-05-06) sets LOG_LEVEL=INFO and LOG_SQL=false. Its release note reads only "Remove built-in OIDC integration". Nothing tells you your database has been accumulating this, or that the update stops it.
2. 3.0.0 is a major version bump, so it does not install automatically, even with automatic updates enabled. Ours sat on 2.1.0 for 85 days after the fix was published, still writing. If you have not manually approved a Fider major update recently, you are probably still on 2.x and still writing.

And the important one: updating does not clean up what already accumulated. The fix stops new rows. The existing table stays, and stays in your backups, until you remove it yourself.

How to check

From the app's Web Terminal:

psql $CLOUDRON_POSTGRESQL_URL -c "SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) \
  FROM pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 5;"

If logs is at the top and measured in GB, this is you.

Server wide, from an ssh session on the box, to see whether any app has a disproportionate dump:

find /home/yellowtent/appsdata -maxdepth 2 -name '*dump' -type f -printf '%s\t%p\n' | sort -rn | head

How to diagnose

Confirm it is the log table and not real content, and check whether it is still growing:

psql $CLOUDRON_POSTGRESQL_URL -c "SELECT count(*) FROM posts;"
psql $CLOUDRON_POSTGRESQL_URL -c "SELECT max(created_at) FROM logs;"

If the newest log row is from before your last Fider update, writing has already stopped and you are only carrying dead weight. If it is from the last few minutes, you are still on an affected package and should update first, otherwise it will simply refill.

Check your package version in the app's About panel. 3.0.0 or later is fixed.

How to fix

Update to 3.0.0 or later first, so it cannot refill. That is a major update and needs manual approval.

Then, if you do not want the old log rows, from the Web Terminal:

psql $CLOUDRON_POSTGRESQL_URL -c "TRUNCATE TABLE logs;"

TRUNCATE returns the disk space immediately. DELETE would not: it leaves dead tuples behind and needs a VACUUM FULL afterwards, which rewrites the whole table and needs free space equal to its size. If you would rather keep recent entries, use DELETE FROM logs WHERE created_at < now() - interval '30 days'; and then VACUUM FULL logs;, and be aware of the exclusive lock that takes.

Nothing in Fider reads this table, so on an install where you have never used it for anything, truncating is safe. Take a backup first regardless.

For us the whole thing was instant: 22 GB to 9.7 MB, and the app's backup went from 3 hours 24 minutes to 19 seconds.

Two suggestions for the package

• Worth a note in the 3.0.0 changelog, or the docs, telling existing installs to prune. The fix is silent, so anybody who updated already still has the table and no reason to suspect it.
• A one time cleanup in the package update, or at least a postInstallMessage, would catch the installs that will never read this post.