Database Size Calculator

Sizing a relational database starts from the row, not the table. Multiply table count by average rows per table by average row width in bytes to get raw tuple data, then add an index allowance and compound the result forward at the expected annual growth rate. Average row width follows from the column types: INTEGER occupies 4 bytes, BIGINT and DOUBLE PRECISION 8 bytes, DATE 4 bytes, TIMESTAMP 8 bytes, and variable-length text costs its actual length plus 1 to 4 bytes of length prefix. A typical business table of 10 to 15 mixed columns averages 200 to 800 bytes per row. Index overhead depends on how many B-tree indexes exist and how wide their keys are; each secondary index commonly adds 10 to 15 percent of table size, so a well-indexed OLTP schema lands at 20 to 50 percent overall. The estimate is deliberately conservative because engines add per-row and per-page bookkeeping the formula ignores. PostgreSQL writes a 23-byte header on every tuple, stores 8 KB pages, and keeps old row versions alive for MVCC until VACUUM reclaims them, so update-heavy tables can occupy well over their logical size. InnoDB uses 16 KB pages and clusters the table on its primary key, which makes a wide or random primary key expensive across every secondary index. Write-ahead logs, temporary sort files, and replica copies live outside this number entirely. Plan on adding 25 to 50 percent above the calculated figure, and revisit the growth assumption annually, since 10 to 20 percent per year is normal for a steady SaaS workload while event and telemetry tables can double in months.

The storage model this calculation rests on comes from two 1970 papers. Edgar F. Codd, working at IBM San Jose, published A Relational Model of Data for Large Shared Data Banks, which established tables of fixed-attribute rows as the logical unit of storage. In the same year Rudolf Bayer and Edward McCreight, at Boeing Research Labs, described the B-tree, whose page-oriented balanced structure became the standard on-disk index and the reason index overhead is estimated as a percentage of table size rather than a fixed cost. IBM built the first practical implementation in System R between 1974 and 1979, introducing SQL and the page-and-segment storage layout that later engines copied. Oracle shipped a commercial SQL product in 1979, and capacity planning grew into a formal discipline through the 1980s when disk was priced per megabyte and a sizing error meant ordering new cabinets. The open-source engines that most of these estimates now target arrived in the mid-1990s: MySQL in 1995 and PostgreSQL, which took its current name in 1996 after evolving from Michael Stonebraker POSTGRES project at Berkeley. Two later additions changed the arithmetic materially. PostgreSQL added TOAST in 2001, transparently compressing and offloading values larger than about 2 KB, and InnoDB became the default MySQL engine in version 5.5 in 2010, making clustered-index storage behavior the norm rather than the exception.