Why your PostgreSQL database keeps growing

pg_database_size measures the PostgreSQL database, while relation functions divide stored objects into table and index components. Those logical measurements are not necessarily the same number shown as provider disk usage.

This read-only query combines current relation sizes with cumulative row-change counters and estimates. Capture the raw bytes, query time, and statistics window when comparing results.

SELECT
  s.schemaname,
  s.relname AS relation_name,
  pg_table_size(s.relid) AS table_bytes,
  pg_indexes_size(s.relid) AS index_bytes,
  pg_total_relation_size(s.relid) AS total_bytes,
  s.n_tup_ins,
  s.n_tup_upd,
  s.n_tup_del,
  s.n_live_tup AS estimated_live_rows,
  s.n_dead_tup AS estimated_dead_rows,
  s.last_autovacuum
FROM pg_stat_user_tables AS s
ORDER BY total_bytes DESC
LIMIT 50;

• New application data, retained history, partitions, materialized views, or extension-managed objects add stored bytes.
• Indexes grow with the table and can grow differently according to indexed values, update patterns, and index type.
• PostgreSQL updates create new row versions. Vacuum normally makes obsolete space reusable inside the relation rather than returning it to the operating system.
• Large values can move into TOAST storage that is included by total-relation measurements.
• Write-ahead log generation and retention can increase provider disk consumption without appearing in pg_database_size.

Standard VACUUM removes obsolete row versions from normal use and makes their space available for future writes. It generally does not return that space to the operating system, so a stable file size after deletes can be expected.

Supabase documents database size, WAL, and system files as separate parts of disk usage. Neon separates compute from durable storage and processes WAL through its Safekeeper and Pageserver architecture. Those models are different, so do not infer provider storage or billing from a logical database-size function alone.

• Estimated dead rows are not a direct measurement of bloat or recoverable disk space.
• A growing index is not proof that the index is unused or should be dropped.
• A larger database is not necessarily unhealthy when retained data and workload have grown.
• Comparing formatted values without timestamps, raw bytes, and matching scope can produce a false trend.
• Provider disk growth is not automatically attributable to tables; WAL and provider-managed data may be separate contributors.

Connected monitoring can chart supported logical database-size observations over 7-, 30-, and 90-day windows. The growth calculator can compare two observations and project a threshold using an explicit linear assumption, while the health check can rank bounded table and index footprints.

DatabaseMeter does not infer the cause of growth from size alone and does not equate logical database bytes with a provider bill. Use the relation, maintenance, workload, and provider evidence together.