Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance - Mailing list pgsql-admin

From Gabriel Guillem Barceló Soteras
Subject Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Date
Msg-id DU0PR08MB7921A4C96214BA4517FD1E39A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com
Whole thread Raw
In response to Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance  (Paul Smith* <paul@pscs.co.uk>)
Responses Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
List pgsql-admin
On 13/01/2026 08:19, Gabriel Guillem Barceló Soteras wrote:
Hi,
We have a healthy PostgreSQL 15 instance (installed from the official Postgres repository) running on Red Hat 9. It serves several databases for internal SMB applications. The environment is stable—apps perform well, disk usage is fine, and the system is not under heavy load.

After integrating PostgreSQL into our monitoring system, I noticed warnings related to VACUUM and ANALYZE. Some tables have never undergone these maintenance operations, or the last run was 30–200 days ago. These databases have very few deletions, and many tables show no growth at all—typical for internal SMB apps.
I know this topic comes up often, but should I schedule a monthly VACUUM + ANALYZE via a cron or systemd timer, while still keeping autovacuum enabled?

We’re also monitoring table bloat, which is currently under 1%, suggesting that manual intervention may not be necessary and that autovacuum is doing its job when needed.
From: Paul Smith* <paul@pscs.co.uk>
Date: Tuesday, 13 January 2026 at 10:50
To: pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance

You would normally not need to do anything manually - autovacuum is sufficient. The main times anything else may be needed is if you do a mass delete or update, in which case the autovacuum may not be updating "quick enough" or you may want to do a "vacuum full" to recover disk space. 

What is your monitoring system looking at that is making it generate those warnings? You need to see what criteria it is using, and then decide whether those matter to you, or if they're false warnings that need adjusting somehow.


Paul

------------------

From: Gabriel

CheckMK, as Anton case, monitors several metrics with a PostgreSQL integration . In this case is last vacuum and analyse. It generates a monitoring item with pre-populated thresholds.

You are not wrong at all. The lazy admin problem is that adjusting monitoring system on per-table basis is very time consuming, compared with  a weekly manual vacuum + analyze that makes 'no harm' out of business hours. I think i will go the weekly vacumdb route, or I will have to deactivate VACUUM and ANALYSE monitoring items.

Thank you!

pgsql-admin by date:

Previous
From: Paul Smith*
Date:
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Next
From: Paul Smith*
Date:
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance