I don't think Stack Overflow's case is a case of "see, you can scale SQL databases". I think it's more of a case of "they've forced themselves to HAVE to scale SQL databases by tying themselves to .Net and MS SQL Server".
There's nothing wrong with relational databases, it's just that many of the NoSQL databases are newer, encourage denormalization, and implement things like intelligent sharding and mapreduce out of the box.
Which one you prefer seems to depend on whether you're more systems-oriented or code-oriented (if you have someone dedicated to tuning your database, why not just let them worry about it?), or whether you're just forced to use one by virtue of the platform you're using.
Having a de-normalized, document-based / column-based / whatever-based NoSQL database doesn't mean that every query or map-reduce function you write in it is going to be super-fast.
I think we all could benefit from articles similar to this one but applied to NoSQL databases: Take a real-world example of a slow-query in a NoSQL database, show how you identified it and profiled it, show how you solved it.
I've personally been burned with performance issues in CouchDB when it came time to perf-test my queries, and I really would have benefitted from articles that detailed a real-world example like this.
I feel like there's a lot of tutorials on how to create toy applications using NoSQL, and a lot of claims on how things like sharding and mapreduce will let you scale to the moon, but comparatively little information on how to do real-world things like what this article covers.
I think it's more a case of "boring but tried and tested" or "new but potentially unreliable". Would you risk your business just to say you use latest tech buzzword?
Things like NoSQL are neat to play with in your spare time, but I'd think long and hard before I'd use them in actual production code. I seem to remember hearing about Cassandra causing woes in the past, for example.
If you're putting your database on your feature page, you probably have other problems than scaling.
It's not about "latest tech buzzword", it's about using the tool that is most appropriate to the job. Cassandra worked up to a point, but it ultimately was not the right tool for the job at Twitter and Facebook scale. Is that cause to be dismissive of all NoSQL databases?
I agree that you should give careful consideration to your technology stack before putting it into production, but to me that means considering all of the options available, not just the old stuff.
This is true, but it should be pointed out that Facebook scales very poorly. Messages disappear/reappear, friends are suddenly missing and suddenly back, your own posts suddenly vanish.
I think Facebook does a pretty decent job considering that they have hundreds of millions of users, with many of them hitting the site many times a day. They've got an absolutely tremendous amount of traffic.
For rapid development, there are a wealth of tools that will just work on SQL databases. No special query language to learn. Jeez, none at all if you use one of the nice ORMs and magic query writing they provide (which was the point of this article). You can even drag and drop your way to a semi-decent app if you know that toolset.
On top of that, you get well-known consistency, transactional updates, and so on. Stuff most developers are used to. So, there's plenty of reasons for picking a traditional SQL database, especially when starting.
Even more so, you don't need to throw SQL away (which is a nice declarative query language) in search of performance. For instance, look at VoltDB/HStore for an example of a SQL-based, table based RDBMS that provides ACID, high performance and linear scaleout. (Granted, with some tradeoffs - it's not for running reports off of, for instance.) On the non-OLTP side, look for massively parallel databases, which still allow SQL while providing amazing scaleout analysis performance. (Downside is that those analysis databases are very expensive; I'm unaware of any cheap or opensource alternative that still uses SQL, except perhaps Pig, but it doesn't really compare, performance-wise.)
Tying yourself to LINQ is one thing, tying yourself to MS SQL Server is completely fine if you're ok with the licensing fees. SQL Server is probably one of the best enterprise databases out there right now, I imagine right behind oracle.
They aren't really tying themselves to LINQ, though. It seems like they're using LINQ to get the dev speed improvement when they can, and dropping down to writing their own SQL in the subset of cases where they know that LINQ isn't fast enough.
Sure, I'm just trying to speak up for some of the less popular technologies in today's dev community :). SQL server has the downside of costing money, but i think it should be in the equation when making technology decisions today, it's a vastly superior piece of tech compared to mysql and postgres :).
There's nothing wrong with relational databases, it's just that many of the NoSQL databases are newer, encourage denormalization, and implement things like intelligent sharding and mapreduce out of the box.
Which one you prefer seems to depend on whether you're more systems-oriented or code-oriented (if you have someone dedicated to tuning your database, why not just let them worry about it?), or whether you're just forced to use one by virtue of the platform you're using.