Hi, We are currently using LakeFS with PostgreSQL. We have allocated a large PVC to PostgreSQL, but we’ve noticed that its memory usage continues to grow, eventually leading to the error: “could not write to log file:

No space left on device"
2026-04-19 23:37:15,504 WARNING: Retry got exception: connection problems
2026-04-19 23:37:15,504 INFO: primary start has timed out, but continuing to wait because failover is not possible

Upon investigating the resource usage of the PostgreSQL pod, we found that the majority of the usage is in the base memory. Could you please recommend a configuration solution? Is there a way to prevent PostgreSQL from consuming excessive memory and to trigger periodic memory release?

4.0K    /home/postgres/pgdata/pgroot/data/pg_commit_ts
4.0K    /home/postgres/pgdata/pgroot/data/pg_dynshmem
4.0K    /home/postgres/pgdata/pgroot/data/pg_notify
4.0K    /home/postgres/pgdata/pgroot/data/pg_replslot
4.0K    /home/postgres/pgdata/pgroot/data/pg_serial
4.0K    /home/postgres/pgdata/pgroot/data/pg_snapshots
4.0K    /home/postgres/pgdata/pgroot/data/pg_stat
4.0K    /home/postgres/pgdata/pgroot/data/pg_tblspc
4.0K    /home/postgres/pgdata/pgroot/data/pg_twophase
8.0K    /home/postgres/pgdata/pgroot/data/pg_stat_tmp
16K     /home/postgres/pgdata/pgroot/data/pg_logical
28K     /home/postgres/pgdata/pgroot/data/pg_multixact
44K     /home/postgres/pgdata/pgroot/data/pg_subtrans
612K    /home/postgres/pgdata/pgroot/data/global
49M     /home/postgres/pgdata/pgroot/data/pg_xact
993M    /home/postgres/pgdata/pgroot/data/pg_wal
469G    /home/postgres/pgdata/pgroot/data/base
470G    /home/postgres/pgdata/pgroot/data

Hi again Yuhao, Sorry to hear you're running into problems. I am hardly an expert in running PostgreSQL at scale, but I will try to help. Firstly, I am unsure whether we are talking about memory or disk usage. The graph seems to be memory usage, but the output of

du -h /home/postgres/pgdata

is probably disk usage. If you have not done so recently, I would probably recommend running VACUUM. IIRC Postgres has autovacuum features, you will probably want to enable them on any production instance.

@Ariel Shaqed (Scolnicov) This feature is enabled by default, but it doesn’t help resolve the issue because the data in the PostgreSQL tables is too large. We’ve found that several tables contain hundreds GB data. I’d like to ask what operations might be causing such large table sizes, and if there are any recommended best practices.

KV holds: • Metadata of uncommitted changes. Every time you upload an object to a branch or delete it - that creates a metadata entry. This basically grows until you commit. Is it possible you have some branches where you never commit? • Commit metadata. You cannot remove this, but typically this will not be so large. The actual paths of a commit are NOT stored in KV - only details like commit message, author, etc. This is probably not your problem. • Branches, tags, etc. - again, this will not be your problem. • More stuff, also unlikely.

@Ariel Shaqed (Scolnicov) During the testing phase, we will delete some branches directly. Is the reclamation of these branches related to the “default retention days” in the GC rule?

AFAIK deleting a branch deletes its KV entries, asynchronously. This code triggers it. It runs DropAsync, which ends up running this, Cleanup itself takes a while, but eventually everything should be dropped. I am not familiar with failure modes of this operation. If it does fail I would expect you to see log floods of

"Dropping tokens failed"

from this line. Unfortunately listing partitions is hard to do on the lakeFS level; you might directly examine the tables in Postgres to see what takes up a lot of space.