Vacuum: PostgreSQL Optimization Advisor & Monitoring for Laravel & Filament

[Heyosseus]

Hello everyone! I built Vacuum - a PostgreSQL monitoring and tuning dashboard for Laravel (with an optional Filament plugin).

It reads what Postgres already knows about itself (pgstat*, pg_class, pg_stat_statements) and turns it into a page that tells you what's wrong, what it's costing you, and the exact SQL that would fix it. It shows you the statement - it never runs it.

What it catches:
Transaction & multixact wraparound - the two clocks that can stop your cluster outright
Table bloat, dead tuples, stale planner statistics, autovacuum misconfiguration
Unused, duplicate, and invalid indexes
Low cache hit ratio, idle-in-transaction sessions, blocked sessions, slowest query shapes

Everything rolls up into a health score out of 100, computed from the findings themselves.

Also in the box:
php artisan vacuum:check - exits non-zero on critical findings, so a migration shipping a duplicate index fails CI
History - optional hourly snapshots, so you get direction (climbing/easing) and forecasts like "wraparound-critical in ~9 days"
Learn at /learn - 13 lessons on Postgres internals worked through your own tables, starting from the Eloquent side (unindexed foreign keys, N+1 as the database sees it, soft deletes, HOT updates)
A read-only SQL console (off by default) that runs everything in a rolled-back READ ONLY transaction

Read-only by design, needs no superuser and no extensions (pg_stat_statements is optional you explicitly open it).

Requires: PHP 8.3+, Laravel 11/12/13, PostgreSQL 14+, Filament 4/5 optional

Feedback is very welcome and you can check it out here: https://github.com/heyosseus/vacuum

[trtajim]

This looks like a really useful tool, especially since it stays read-only and explains why a recommendation is made instead of automatically applying changes.

I have one question about the health score. Since different applications have very different workloads, how did you decide on the weighting for each metric? For example, how do you balance something like table bloat against an unused index or a low cache hit ratio?

I'm curious whether the scoring is based on PostgreSQL best practices, your own experience, or if it's configurable for different environments.

[Heyosseus]

Hi, that's a really good question. You can check config/vacuum.php and adjust the definitions, weights, and thresholds based on your application's needs. However, the score isn't a second opinion. It's 100 minus what the findings cost, and nothing else:

$score = max(0, 100 - array_sum($findings));

Weight lives on severity, not on the metric. Bloat, unused index, and cache hit ratio are never ranked against each other. Each rule decides its own severity from its own thresholds

Critical => 15,
Warning => 5,
Info, Unknown => 0,

Info costs nothing. So "table bloat vs. unused index" isn't a question the scorer answers. Unused Index is always a Warning. TableBloat and CacheHitRatio are Warnings that escalate to Critical if you configure a harsher threshold.

Also, it's worth mentioning that forty bloated tables are one problem, not forty.