It depends. There, I said it. The data file itself will be there to contain the data. The size depends on the amount of data being held. I'm sure there are tools out there to help you size a database given the table structures and numbers of rows of data etc. The log file is there to contain changes to the data before they are backed up. The size of this depends upon the sort of queries being run - a simple `SELECT` statement shouldn't affect the log size, but any data-changing activities (`UPDATE`, `INSERT`, `DELETE`) and object creation / alteration etc. The tempDB also has data & log segments; again, the use of this will depend upon the query load that your database/server experiences - more complex queries will make greater use of the TempDB than simple queries. So, without knowing (a) the sort of data, and (b) the sort of use, you can't specify this. Some reading material for you: * [Estimating disk space requirements for databases] * [The Basics of Sizing a SQL Server Database] :
Without tons more knowledge, how many users, what anticipated load, how many transctions, what size transactions, etc., you can't know how to estimate size & growth. However, with 15gb of data, I'd make the data size about 25gb to allow for growth (these are very small databases, so you don't need to worry about multiple files and file storage yet, but additional information could change that). I'd make the log about 5gb, and that assumes full recovery and a regularly scheduled log backup (every 15-20 minutes). Tempdb... that's harder to size, but probably around 10gb, assuming no other databases on the system. Sizing tempdb is completely different than sizing a single database, so that's just a complete SWAG (silly wild-a***d guess). But to do this correctly, you need lots more information than just the current size of the data.