On twitter today I saw some discussions about caching in regards to databases. Included in those discussions were talks about NoSQL, such as MongoDB. Here’s my take on the subject. SQL Server has a built in caching mechanism which takes data, execution plans, etc. and keeps them resident in memory. If you have much more memory than data, chances are that all the requested pages will keep themselves available. All flavors of NoSQL can be thought of as simply a way of storing data in memory, most often in key-value pairs. If you are trying to do simple key value lookups, from both a database and say my favorite flavor of NoSQL, AppFabric Cache, the response time is going to be eerily similar. The reason for that is you are looking for the key in memory in both cases, and returning the “payload”, which is the columns in the database or the value in the cache. The reason the SQL Server takes a bit longer is that it has to “translate” your SQL into a request to get the information, where as in AppFabric Cache, you are simply making a request for the value which corresponds to that key. In my testing, I found that responses from AppFabric Cache on average took .4ms and the same request from the SQL Server database took .6ms. Both of these were simple key value lookups, and the data from SQL Server had already been cached. The extra .2ms can be thought of as the overhead of translating the SQL and putting together the response.