I thank them for releasing this.
I thank them for releasing this.
It's much more effective and efficient to use a SQL query than it is to throw together a huge amount of imperative JavaScript code (that's usually very specific to a single NoSQL database, as well) merely to perform the equivalent query.
It's much safer to use a database that offers true support for transactions and constraints, rather than trying to hack together that functionality in some Ruby or PHP data layer code, or relying on some vague promise of "eventual consistency", for instance.
It's much more maintainable, and leads to higher-quality data, to spend some time thinking about a schema, rather than just arbitrarily throwing data into a schema-less system, and then having to deal with the lack of a schema throughout any application code that's ever written.
Aside from an extremely small and limited handful of situations (Google and Facebook, for instance), relational databases are the best tool for the job.
Honestly. I don't think you could be more misinformed if you tried.
Hint: Google "Big Data".
Of course, it's understandable why they have a bad impression of SQL; they've only ever used one of the most inept implementations around.
Those who are willing to try one of the more mature and sensible relational database systems usually see quite quickly the value that such systems provide.
If there are production-ready options for biggish data other than NoSQL or high priced commercial analytics dbs, please share...
Also, your comment is rather ambiguous, I certainly hope you're not calling Postgresql experimental, because that would be laughable; and there are several examples of multi-terabyte databases using it.
SQL is NOT always the right tool for the job.
There are plenty of situations where an Hadoop or a Storm/S4 approach works better. Again it's about picking the right technology for the task at hand.