How accurate is this estimate?

The estimate is based on well-known internal formulas for each engine (page size, tuple overhead, alignment padding). Real sizes may vary ±20% depending on data distribution, vacuuming state, and OS block size. Use it for planning, not billing.

Fill factor controls how full each index page is when first written. A fill factor of 80% leaves 20% of each page empty to reduce page splits on future inserts. Lower fill factor means a larger initial index but fewer splits under write-heavy workloads.

Does this include the table (heap) size?

No. This tool estimates only the index structure. The table heap is a separate allocation. For a full storage budget, add your estimated table size on top.

Why does a Hash index sometimes appear smaller than B-tree?

Hash indexes store a fixed-size hash value per entry instead of the actual key bytes, so they can be smaller for long variable-length keys. However, they only support equality lookups and are not suitable for range queries.

Can I estimate a composite index?

Yes. Add multiple columns using the Add Column button. The tool sums the per-column byte widths to compute the composite key size.

Database Index Size Estimator

Estimate how much storage your database index will consume by selecting column types, row count, and index type.

Index Configuration

Database Engine

Index Type

Number of Rows

Fill Factor: 80%

10% (fewer splits) 100% (compact)

Indexed Columns

Configure your index and click Estimate Index Size to see results.

Total Index Size

—

Size per Row

—

Breakdown

Component	Bytes / Row	Total

Copied!

Summary

Estimate how much storage your database index will consume by selecting column types, row count, and index type.

How it works

Select your database engine (PostgreSQL, MySQL InnoDB, or SQL Server).
Add one or more indexed columns and choose their data types.
Enter the expected number of rows in the table.
Choose the index type and fill factor.
Click Estimate to see the projected index size with a breakdown.

Use cases

Capacity planning before deploying a new index on a large table.
Comparing B-tree vs. Hash index storage cost for a given column.
Estimating disk requirements for a new database schema.
Justifying index consolidation or removal based on storage cost.
Teaching database internals and explaining index overhead.
Benchmarking storage impact of composite vs. single-column indexes.

Frequently Asked Questions

Last updated: 2026-09-19 · Reviewed by Nham Vu