Joe / Mark,
Actually SQL Server databases (2000, 2005 and 2008 - cant vouch for 7.0) are by default self expanding. You can configure how much you want to increase the DB size by when it reaches a specific level at DB creation time and also at a later time. Hosts configure them with certain top limits and they demand you to pay more when you run out of space.
And there is a hidden secret here which I am not sure how many merchants know of. Every SQL database has 2 files on the file system. A db file (has a mdf extension by default) and a log file (has a ldf extension by default). These extensions can be changed to anything else as well. What really grows in size rapidly is the log file size and not the database file size. And do you know why the log file size grows so rapidly? Its because of the recovery model set for your database. By default when you create a database, the recovery model is set to Full. Read this article:
http://msdn.microsoft.co...us/library/ms175987.aspx for more information on recovery models.
Now having said that, irrespective of what recovery model you choose, you can always shrink the database file size (especially the transaction log file size). This is an admin operation and is pretty straight forward. Else what you end up with is huge transaction log file sizes.
For instance, I know of one customer whose transaction log file size grew to 14 GB because they never shrink the transaction log. In that case, your store performance will come down. And not just that, the host was charging more and more every month. The speed at which your transaction log file size increases depends on the number of DB transactions happening. If yours is a high traffic store, expect your transaction file to grow very fast.
On top of this, if you have a huge transaction file size, then backup and restore also takes a lot of time. For instance the database that I am talking about here (the one with a transaction log file size of 14 GB), a restore database from full backup took almost 35 minutes. You definitely dont want to be in that situation. Overall with huge transaction log file sizes, you will sacrifice performance, money and risk DB restores.
However, database and transaction log files should be reduced in size in a proper way taking into account what you would want to restore and what not. It also depends on how often your DB gets backed up. It should be carefully planned and very few people can advise you on how to shrink the DB and transaction log file sizes. Thats a niche area. :-)
To know your database transaction log file size, ask your host for a full database backup. Restore it on your server and notice the file sizes. Alternatively ask your host for the file sizes. If your log file is not huge and if your store is slow, then there is something else going on. :-)
Let me know if you have further questions.