Why this problem matters
PostgreSQL disk use can grow through real data, indexes, WAL retention, temporary files, or bloat. Filesystem totals alone are insufficient for choosing the right response.
How to diagnose it
Compare database and relation sizes over time, then inspect WAL and temporary-file counters separately. PostgreSQL size functions may not include logs or other application files on the same filesystem.
The queries show allocated database sizes and the largest user tables. Host metrics are still required for filesystem free space and detailed pg_wal usage.
SELECT datname, pg_database_size(datname) AS database_bytes
FROM pg_database
WHERE datallowconn
ORDER BY database_bytes DESC;
SELECT schemaname, relname,
pg_total_relation_size(relid) AS total_bytes
FROM pg_stat_user_tables
ORDER BY total_bytes DESC
LIMIT 25;A safe solution approach
After classifying the growth source, address data lifecycle, index design, queries, or WAL retention. Plan capacity expansion alongside root-cause work and a safe free-space margin.
Why continuous monitoring matters
moon helps continuously monitor PostgreSQL object and capacity trends with low overhead. Slack, PagerDuty, or webhook alerts expose changes in growth rate early.
Frequently asked questions
Does database-size growth always mean more application data?
No, indexes, dead rows, and other relation forks may also contribute. Separate the source at object and time-series level.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.