Postgres Table Size Estimator

How big will this table actually get? Enter your columns and an expected row count and this calculator works out the on-disk size the way PostgreSQL does: a 23-byte tuple header, a null bitmap when any column is NULLable, alignment padding between values, MAXALIGN rounding, the 4-byte item pointer each row costs in its page, and how many rows then fit in an 8 KB page at your fillfactor. It also estimates B-tree index sizes and shows how much space you would save by reordering columns. Everything is computed in your browser — no schema or data leaves your machine.

Row countFillfactor

Columns — `name type`, add `null` if NULLable, `avg=N` for text/jsonb width

Indexes — one per line, comma-separated key columns

Estimate

Rows: 10,000,000   fillfactor: 100
Usable space per 8 KB page: 8168 B → 28 rows/page
Heap pages: 357,143
Estimated heap (table) size: 2.72 GB
Estimated index size: 986.9 MB
Estimated total relation size: 3.69 GB

Column order: already optimal — no alignment padding to reclaim by reordering.

Row layout breakdown

tuple header                        23 B
null bitmap (7 cols, has NULLable)  1 B
header padded to MAXALIGN(8)        24 B

column                offset  size  padding  note
id                        24     8        0  fixed length
created_at                32     8        0  fixed length
is_active                 40     1        0  fixed length
score                     44     4        3  fixed length
email                     48    29        0  variable, 28 B avg + 1 B short header
nickname                  77    13        0  variable, 12 B avg + 1 B short header
payload                   92   188        2  variable, 180 B avg + 4 B header + 4 B jsonb header

user data                           256 B
row padded to MAXALIGN(8)           280 B
+ item pointer in page              4 B
= cost per row inside a page        284 B

Index estimates

  btree (id) → 20 B/entry, 366 entries/page, 27,399 pages ≈ 214.1 MB
  btree (email) → 44 B/entry, 166 entries/page, 60,605 pages ≈ 473.5 MB
  btree (created_at, is_active) → 28 B/entry, 262 entries/page, 38,315 pages ≈ 299.3 MB

Verify against a real table

-- Compare this estimate with the real numbers once the table exists:
SELECT pg_size_pretty(pg_relation_size('my_table'))       AS heap,
       pg_size_pretty(pg_indexes_size('my_table'))        AS indexes,
       pg_size_pretty(pg_total_relation_size('my_table')) AS total;

-- Average real row size and how many rows fit per page:
SELECT reltuples::bigint AS est_rows,
       relpages          AS pages,
       CASE WHEN relpages > 0 THEN reltuples / relpages END AS rows_per_page
FROM pg_class WHERE relname = 'my_table';

-- Per-column average width, straight from the planner statistics:
SELECT attname, avg_width, null_frac
FROM pg_stats WHERE tablename = 'my_table' ORDER BY avg_width DESC;

Notes

• PostgreSQL stores every row with a 23-byte header, a null bitmap when the table has any NULLable column, and padding so each value starts on its alignment boundary. That overhead is why 7 small columns rarely add up to the size you expect.
• Values wider than about 2 KB are compressed and moved to the TOAST table, so a big text or jsonb column often makes the main heap smaller than this estimate while pg_total_relation_size stays large. Check pg_stats.avg_width for the real stored width.
• This is a fresh, perfectly packed estimate. A live table also carries dead tuples between vacuums; 10–20% bloat is normal and a table that never gets vacuumed can be several times larger.
• Index estimates assume a B-tree with the default fillfactor of 90 and no deduplication. PostgreSQL 13+ deduplicates repeated keys, so indexes on low-cardinality columns are usually smaller than shown here.
• Reordering columns from widest alignment to narrowest (bigint/timestamptz first, boolean and varchar last) removes padding without any behaviour change — the savings line above shows what that is worth for your row count.

Do more than postgres table size estimator — meet Chat2DB

Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.

How to use

List your columns one per line as `name type`, adding `null` for NULLable columns and `avg=N` to set the average byte length of text or jsonb values.
Enter the expected row count and the table's fillfactor (100 for append-only tables, 70–90 for heavily updated ones).
List one index per line as a comma-separated key column list, then read the estimated heap size, index size and the column-order savings.

Frequently asked questions

How do I calculate the row size of a PostgreSQL table?

Start with the 23-byte HeapTupleHeaderData, add a null bitmap of ceil(columns/8) bytes if any column is NULLable, and round that up to a multiple of 8 (MAXALIGN) to get t_hoff. Then lay out each column in order, padding to its type alignment: bigint, double precision and timestamptz align to 8, integer and date to 4, smallint to 2, boolean and uuid to 1. Round the whole row up to a multiple of 8 and add 4 bytes for the item pointer in the page. That is the number this tool computes per row.

Why is my table bigger than the sum of its column sizes?

Three reasons: the per-row header and item pointer add ~27 bytes to every row no matter how narrow it is, alignment padding inserts dead bytes between columns of different widths, and dead tuples from UPDATE and DELETE stay in the table until VACUUM reclaims the space. Indexes are counted separately — pg_relation_size shows only the heap, while pg_total_relation_size includes indexes and the TOAST table.

Does column order really affect table size in PostgreSQL?

Yes. Because each value must start on its alignment boundary, a layout like (boolean, bigint, boolean, bigint) wastes 7 bytes of padding after each boolean, while (bigint, bigint, boolean, boolean) wastes none — 14 bytes per row, which is 140 MB across 10 million rows. Ordering columns from widest alignment down to narrowest, with variable-length text last, is free to do at CREATE TABLE time. To inspect real tables, row widths and index sizes across PostgreSQL, MySQL and 20+ other databases, use Chat2DB — download it at https://chat2db.ai/download or open the web version at https://app.chat2db.ai.