Estimate B-tree index size from row count, key width, and pointer size. Plan database index storage for any RDBMS engine.
Database indexes dramatically improve query performance, but they come at a storage cost. Every B-tree index stores a sorted copy of the indexed columns plus internal pointers that link tree nodes together. As tables grow to millions or billions of rows, index sizes can rival or exceed the base table size—especially when multiple indexes exist on the same table.
This calculator estimates the on-disk size of a B-tree index using the fundamental formula: rows × (key width + pointer size) × overhead factor. The overhead factor accounts for B-tree node fill rates (typically 67–90%), internal node storage, page headers, and alignment padding. By understanding index size before you create one, you can make informed decisions about which indexes to add, which to drop, and how much storage to provision.
Whether you're sizing a new index on a multi-billion-row analytics table or auditing existing indexes for a capacity review, this tool gives you a fast, reliable estimate.
Creating an oversized index can exhaust disk space and slow write operations. Not creating a needed index degrades query performance. This calculator helps you find the right balance by estimating index storage before deployment, so you can plan capacity and prioritize which indexes provide the best performance-per-byte tradeoff. Regular monitoring of this value helps DevOps teams detect anomalies early and maintain the system reliability and performance that users and business stakeholders expect.
index_size = rows × (key_bytes + pointer_bytes) × overhead_factor; total_index_storage = index_size × number_of_indexes
Result: 1.26 GB per index; 3.77 GB total
50 million rows × (12 + 6) bytes = 900 MB raw. With a 1.5× overhead factor (accounting for ~67% fill rate and internal nodes), each index is approximately 1,350 MB (1.26 GB). Three such indexes total 3.77 GB of index storage.
A B-tree index is a balanced tree with leaf nodes containing the indexed key values and pointers back to heap rows. Internal nodes contain separator keys and child page pointers. The depth of the tree is typically 3—4 levels for tables up to billions of rows, keeping lookups fast.
When an index page fills up, it splits into two half-full pages. Over time, random inserts cause fragmentation that bloats index size beyond the theoretical minimum. Periodic REINDEX or ALTER INDEX REBUILD operations reclaim this wasted space. Set FILLFACTOR below 100 for write-heavy workloads to leave room for future inserts.
For initial capacity planning, estimate each index at 1.3–1.5× the raw key+pointer size. After the database is running, validate with actual statistics. Consider dropping low-selectivity indexes on columns with few distinct values—they consume space without improving query plans.
B-tree nodes are not 100% full. The default fill factor is typically 70–90%, meaning 10–30% of each page is empty. Internal (non-leaf) nodes add further overhead. An overhead factor of 1.2–1.5 accounts for these inefficiencies.
Sum the byte sizes of every column in the index. For example, an index on (user_id INT, created_at TIMESTAMP) would be 4 + 8 = 12 bytes. Add alignment padding if your database requires it (e.g., 8-byte alignment in PostgreSQL).
The pointer links leaf nodes to heap tuples. In PostgreSQL it's a 6-byte TID (block number + offset). In MySQL InnoDB, the clustered key itself acts as the pointer, so add the primary key width. A value of 6–8 bytes is typical.
This formula targets B-tree indexes specifically. GIN, GiST, BRIN, and hash indexes use different storage strategies. BRIN indexes are much smaller; GIN indexes can be larger due to posting lists. Adjust the overhead factor or use engine-specific tools for those types.
In PostgreSQL, NULLs are indexed by default and consume space for the null bitmap. In MySQL InnoDB, NULLs take 1 byte in the record header. If many rows have NULL indexed columns, actual size may be slightly less than estimated.
Yes. Total index storage often equals 30–60% of the data size for OLTP workloads and can exceed 100% for heavily indexed analytics tables. Always include index storage in capacity planning.