+ 0 Votes hm... Rob Kuhn 1 year ago Without really knowing what your app is doing makes it a challenge to post a recommendation.I don't know if it's disk I/O intensive in which case you will want to look at using SAS drives instead of SATA drives. I don't recall how licensing is for SQL 2008 (don't recall if it's per core or per CAL). If the data base is just there to hold meta data and serve as a repository then you may not need more than one core dedicated to SQL.I assume you're going to go with the 64 bit version for both OS and SQL. Anything less and I would have to recommend you split the two. In other words you could have the frontend web server be Windows 2003 R2 -32 Bit with 4 GB of RAM and a single dual or quad core CPU (it just needs to run IIS). The backend SQL server I would go 64 bit with at at least 8 GB or RAM (more if budget allows) and a single dual or quad core CPU to start (but with a motherboard that can support a second or more CPUs).But since this is a "small" installation, a single dual or quad core CPU with at least 8 GB is where I'd start ... if you could get more RAM I'd go for it. Go RAID-1 for your boot drive and at least RAID-5 or 6 for your data. If you don't expect the data to grow too large you could get away with a pair of 2TB drive in a RAID-1.Just too many options without really knowning what your app is doing... :) + 0 Votes Reponse To Answer sysdevcbc24 1 year ago Hello Rob.The web application im developing is a utilities application, etc. etc., but mainly acts as a reports generator. Before, we have medium-weight distributed applications per workstation that does a couple of small things. Since space, bandwidth, maintenance, and security (and the list of issues continue) are already taking its toll, we decided to centralize.Since this app plays as a reports generator, it get its data from another source. The data that forms the report output comes from another database from another machine. After generating the reports, we'll be storing them on the same machine where the app resides for easy download, through this app.Where will the SQL server come to play? Here goes one scenario. Some data, especially balances, from the source database change from time to time. The SQL server will then act as a middle-man and will store those volatile data for further use. We're doing this because they give us small leeway in terms of access and changes to the source database.I understood the points you've mentioned about the 32-64 bit comparison and memory needs, and the others. What I didn't understand is the RAID thing. To be honest, I don't have the slightest idea. If you're not too busy, I'd be grateful if you'd expound on it.Thank you very much by the way for the response.