Table Size Calculator

About the Table Size Calculator

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.

When This Page Helps

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.

How to Use the Inputs

1. Enter the total number of rows in the table.
2. Enter the sum of all column sizes in bytes per row.
3. Enter the per-row overhead (23 bytes for PostgreSQL, 13 for MySQL InnoDB).
4. Review the total table size on disk.
5. Compare with actual table size using database system views.

Example Calculation

Tips & Best Practices

• Use pg_total_relation_size() in PostgreSQL to verify estimates against actual on-disk size.
• Variable-length columns (VARCHAR, TEXT) use actual data length, not maximum declared length.
• NULL columns save space—a NULL value uses just 1 bit in the null bitmap.
• Alignment padding rounds column offsets to 4 or 8 bytes, adding invisible overhead.
• TOAST-able columns (>2KB in PostgreSQL) are compressed and stored out-of-line automatically.
• MySQL InnoDB stores rows in 16 KB pages with ~50–75% fill factor due to B-tree structure.

Column Type Size Reference

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.

Page Overhead and Fill Factor

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%.

Validating Estimates

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.

Frequently Asked Questions

• What exactly is row overhead?

  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.

• How do I calculate column sizes?

  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.

• Does this include index 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.

• Why is the actual table larger than calculated?

  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.

• How does compression affect table size?

  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.

• Should I account for table bloat?

  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.