Actually real question is, is there a cache like mechanism (DB in memory ?) making this worthy?
You have to remember that SQL Server or whatever DBMS you use will have its trade offs, but more importantly you have to think about how your application uses and serves this data to its clients to truly nail down what those trade offs will be.
At my current job we use a 2 layer stack, the first and more permanent storage are SQL server database instances that are built on a CQRS (Command Query Read Segregation) model and the most recently/frequently accessed data is cached in RavenDB.
The cool thing that we implemented recently was segregating the data into "components" to get a higher probability of hitting something in our RavenDB store. An example of what I mean by this is, instead of storing the player's entire save in the cache, you store pieces of it (their items, pieces of their skill tree, etc) separately so when you go to fetch a different player's save, most of that information is already cached and can be rebuilt without even hitting the database. The power of permutations will play in your favor this way, allowing you to load 90% or more of players' information from the fast NoSQL cache instead of having to do costly queries on the SQL DB.
CQRS is basically a way to scale your database queries (reads) independently of your database write operations (writes/updates). Yes, tweets come in at large volumes, but 90% of the time a client is fetching data. This goes more in depth: http://martinfowler.com/bliki/CQRS.html
Hope this helps!