Vacuum Laravel Package

Product Decisions This Supports

• Upgrade scheduling. v1.2.3 is a drop-in patch — no config changes, no migrations, no API changes. That removes the usual "wait for a maintenance window" friction and makes "upgrade now" the default decision. Rollback is a version pin.
• Whether the dashboard can ship to production. On a 160 GB / ~500-table database, the Overview's two size queries ranked first and second in pg_stat_statements across every role, running pg_total_relation_size() over every table on every render with no statement timeout. That's a cost-of-ownership finding, not a cosmetic one: it's the difference between letting DBAs use the Overview on prod and restricting it to staging.
• Accepting a graceful-degradation contract. Size reads now run through the read-only executor and are bounded by the statement timeout; a database too large to size in time gets a placeholder chart instead of a held web worker. PM call: is "degraded message" acceptable UX for your users, or does it need to be a blocking requirement? Decide once, write it down.
• Freshness tradeoff. Largest tables no longer polls every five seconds. Is fetch-on-render freshness enough for the "who's bloating" use case? If yes, close the topic; if no, file a requirement rather than carrying an unstated expectation.
• Carrying known debt with an owner. The Tables list still sorts by size on each load (#31). Treat it as accepted, tracked debt with a public issue number instead of re-litigating it each release.
• Data fidelity check. Database size now comes from pg_database_size() and includes the system catalogs (~0.03%). Small, but confirm no alert threshold, capacity-planning sheet, or customer-facing report assumes the old figure.
• Build vs buy. A community contributor measured, reported, and fixed a real production-scale performance bug (#30, follow-up #32). That's maintenance you don't staff — a concrete point in favour of consuming this package rather than writing your own overview page.
• Roadmap input. If you self-host across many clusters, the remaining per-load sort (#31) becomes your capacity item. If you run one dashboard, it's noise.

When to Consider This Package

Adopt if:

• You run Postgres in production and want an in-app view of database size, largest tables, and vitals without standing up a separate monitoring stack.
• Your databases are large enough that pg_total_relation_size() across every table on every render is a genuine problem — i.e. exactly what this release fixes.
• You can point the package at a read-only DB role and accept statistics reads bounded by statement timeout.
• You can live with a degraded chart, rather than a hard failure, on databases too large to size in time.

Look elsewhere / don't adopt if:

• You need sub-five-second freshness on table sizes — this release deliberately removed the 5s poll.
• You need exact, catalog-excluded size accounting for billing or hard capacity thresholds (0.03% inflation is small but real).
• You need a full APM/metrics product (histograms, retention, alerting). pg_stat_statements plus this Overview is not that.
• You cannot tolerate the known per-load full sort on the Tables list (#31) on very large schemas and need it fixed before rollout.
• You're on MySQL/SQLite, or outside Laravel.

Caveat on the source material: the published notes are partially truncated ("sahat", some clause endings). The substance — two query rewrites, timeout bounding, poll removal, no API/config/migration changes — is clear enough to act on, but confirm the exact degradation behaviour in the changelog before promising it to stakeholders.

How to Pitch It (Stakeholders)

Executives: A one-line upgrade that removes a real production performance problem in our database monitoring view. On a 160 GB database, the Overview was running the two most expensive queries in the entire system on every page render, with no timeout — enough to hold a web worker for up to a minute. After this patch those become cheap, bounded reads. No migrations, no configuration, no API changes: it's a composer update. Low risk, immediate stability and cost win, and the work was contributed by the community rather than built by us.

Engineering: v1.2.3 reworks the Overview's expensive paths. Database size now uses pg_database_size() (includes system catalogs, ~0.03% delta) instead of aggregating pg_total_relation_size() across every table. Largest tables now runs through the read-only executor so the statement timeout applies, and the five-second poll is gone. The vitals card reads each figure once per render, down from computing a ratio three times and active sessions twice. Two caveats to plan around: the Tables list still sorts by size on every load (#31, tracked upstream), and very large databases may render a degraded chart instead of a number. Upgrade via composer update heyosseus/vacuum; rollback is a version pin.