Estimating database size

Question

I was wondering what you do when developing a new application in terms of estimating database size.

E.g. I am planning to launch a website, and I am having a hard time estimating what size I could expect my database to grow. I don't expect you to tell me what size my database will be, but I'd like to know if there are general principles in estimating this.

E.g. When Jeff developed StackOverflow, he (presumably) guesstimated his database size and growth.

My dilemma is that I am going for a hosted solution for my web application (its about cost at this stage), and preferably don't want to shoot myself in the foot by not purchasing enough SQL Server space (they charge a premium for this).

Solution

If you have a database schema, sizing is pretty straightforward ... it's just estimated rows * avg row size for each table * some factor for indexes * some other factor for overhead. Given the ridiculously low price of storage nowadays, sizing often isn't a problem unless you intend to have a very high traffic site (or are building an app for a large enterprise).

For my own sizing exercises, I've always created an excel spreadsheet listing:

• col 1: each table that will grow
• col 2: estimated column size in bytes
• col 3: estimated # of rows (per year or max, depending on application)
• col 4: index factor (I always set this to 2)
• col 5: overhead factor (I always set this to 1.2)
• col 6: total column (col 2 X 3 X 4 X 5)

The sum of col 6 (total column), plus the initial size of your database without growth tables, is your size estimate. You can get much more scientific, but this is my quick and dirty way.

Comments

[warren]

you type too fast! that's almost exactly what I said :)

[Beep beep]

Good answer - the fudge factors are the most important part of database sizing ... as we said when I was a consultant "if the # looks too low, just throw in another fudge factor".

[Ash M]

Thanks for all your help guys, i think this gives me a good starting place.

[Cathy Sullivan]

Does the database do any compression on the data? That would add a different factor that would make the whole thing smaller.