I think you would have to qualify your statement "it's handling everything just fine.". Does that mean that SQL Server is not having large request queuing? If SQL is not a bottleneck, you would have to find out what is. In general, it is easier and more cost-effective to scale out application logic tiers of a multi-tier application, than the database server. this is the general rule I think is true, probably for all relational databases. Usually you only get one database server, and it is very very expensive to scale. SQL Server enterprise is $4k / cpu core. Long-running requests that perform business logic could easily cause request queuing and blocking problems for SQL Server. An application will typically just sit there waiting for a response from the db server. The longer it waits, the less performant it will be, or at least seem to be. If you keep the requests to the database shorter-running (more granular, e.g. simple select statements that use indexes and only bring back the data you actually need), then your application servers will spend less time waiting for reponses from SQL, SQL will spend less time performing logic and more time retrieving data which is what it excels at. The queueing will be reduced on the database server, and you can increase the # of application servers and experience a predictable increase in the application's capacity to handle more. another thought just occurred to me, it sounds like your 25 web/app servers are all hitting the database directly. perhaps there is a case for creating a data access tier on a separate (small) set of servers that does all the database communications. using that approach you could implement some caching there. I would do a POC and also see if it makes sense to put the business logic in that same tier. anyways, that's my 2cents, hope that helps