Calculate the on-disk size of a database table from row count and column definitions. Accounts for row overhead and alignment padding.
Knowing the on-disk size of a database table is essential for capacity planning, migration sizing, and query optimization. The actual row width includes not just the column data, but also row headers (23 bytes in PostgreSQL, 13 bytes in MySQL InnoDB), null bitmaps, alignment padding, and page overhead. A table that looks like 100 bytes per row in the schema may actually occupy 140–160 bytes on disk.
This calculator lets you enter the row count and total column sizes, apply per-row overhead, and compute the total table size. It accounts for the row header and general padding that vary by database engine.
This analytical approach supports proactive infrastructure management, helping teams avoid costly outages and maintain the service levels that users and business stakeholders depend on. By calculating this metric accurately, DevOps and engineering professionals gain actionable insights that drive system reliability, scalability, and operational excellence across environments.
This analytical approach supports proactive infrastructure management, helping teams avoid costly outages and maintain the service levels that users and business stakeholders depend on.
Schema definitions show logical column sizes, not physical storage sizes. This calculator adds the per-row overhead that database engines impose, giving you accurate on-disk size estimates for capacity planning and migration scheduling. Consistent measurement creates a reliable baseline for tracking system health over time and identifying degradation before it impacts users or triggers costly production outages.
row_physical_size = column_sizes_total + row_overhead; table_size = row_count × row_physical_size
Result: 864.5 MB
Each row occupies 150 bytes of column data + 23 bytes of PostgreSQL tuple header = 173 bytes. For 5 million rows: 5,000,000 × 173 = 865,000,000 bytes ≈ 824.9 MB plus ~5% page overhead brings the total to approximately 866 MB.
Common column sizes in bytes: BOOLEAN=1, SMALLINT=2, INT=4, BIGINT=8, FLOAT4=4, FLOAT8=8, NUMERIC=variable (2 bytes per 4 digits + 8 overhead), TIMESTAMP=8, DATE=4, UUID=16, TEXT/VARCHAR=actual length + 1–4 bytes, JSONB=actual size + 4 bytes.
Database pages (8 KB in PostgreSQL, 16 KB in MySQL) have headers that waste some space. The fill factor setting controls how full each page is packed—lower fill factors (e.g., 70%) leave room for updates but waste more space. Default is usually 90–100%.
Always validate estimates against reality. In PostgreSQL: SELECT pg_size_pretty(pg_relation_size('tablename')). In MySQL: SELECT data_length FROM information_schema.tables WHERE table_name='tablename'. Compare periodically and adjust your model.
Row overhead includes the tuple header (version info, transaction IDs, null bitmap pointer) that the database engine stores with every row. PostgreSQL uses 23 bytes, MySQL InnoDB uses 13–20 bytes, SQL Server uses 7–14 bytes depending on null columns.
INT=4, BIGINT=8, SMALLINT=2, BOOLEAN=1, FLOAT=4, DOUBLE=8, TIMESTAMP=8, UUID=16, CHAR(n)=n, VARCHAR(n)=actual avg length + 1–4 bytes overhead. Sum all columns for the total row data size.
No. This calculates only the table (heap) size. Indexes add additional storage. Use the Database Size Estimator or Index Size Calculator for total database storage including indexes.
Page overhead (8 KB pages have 24-byte headers in PostgreSQL), alignment padding between columns, fill factor (default 90% in PostgreSQL), and dead tuples from UPDATE/DELETE operations all increase actual size beyond the simple calculation. Comparing your results against established benchmarks provides valuable context for evaluating whether your figures fall within the expected range.
PostgreSQL TOAST automatically compresses values over ~2 KB. MySQL InnoDB page compression can reduce size by 50–70% for compressible data. SQL Server offers row and page compression with different trade-offs between size and CPU cost.
Yes, for MVCC databases like PostgreSQL. Dead rows from UPDATE and DELETE accumulate until VACUUM reclaims space. A table with heavy modification can be 20–50% larger than expected. Set up autovacuum properly to control bloat.