Use built-in size functions to report the exact on-disk bytes a specific table (and its indexes) occupy.
Table growth signals rising storage costs, longer backup times, and slower queries. Knowing size trends lets you archive old data, add partitions, or increase hardware before performance drops.
Use pg_table_size()
for the heap only, pg_indexes_size()
for indexes, and pg_total_relation_size()
for heap + toast + indexes. Wrap them in pg_size_pretty()
for human-readable output.
Select pg_size_pretty(pg_total_relation_size('"Orders"'))
. This returns a formatted string such as 256 MB.
Order every table by pg_total_relation_size
descending. This highlights storage hotspots that need pruning or indexing tweaks.
Schedule a nightly query in cron or pgAgent to write current sizes to a metrics table. Plot results in Grafana to catch sudden spikes.
See the syntax and ecommerce example below.
No. It reads catalog statistics and system files, so it doesn’t block reads or writes.
Yes. pg_total_relation_size automatically adds TOAST and index sizes, giving a complete picture.
Store daily sizes in a monitoring table and graph them. Sudden jumps often reveal runaway logs or missing partitions.