Maybe I'm misunderstanding your comment but... Real businesses need real solutions for their use cases. SQL is not necessarily the right tool for "that" job.
If such a "solution" involves safely querying, analyzing, storing and manipulating data in any way, SQL and relational databases are usually the best option in practice.
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.
...data warehouses in general mostly use SQL, and lots of businesses use data warehouses successfully. Teradata, Netezza, Oracle, DB2, etc. I'm not sure why his statement was controversial - SQL's a great language for reporting and analytics.
I've had to deal with a lot of NoSQL advocates whose experience with SQL or relational databases doesn't extend beyond MySQL.
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.
Considering the space requirements of a DB with a properly designed schema, I have to wonder what on earth you can do that generates beyond a few terabytes of data, and how you can make any sense out of it.
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.
>Real businesses need a data warehouse and SQL is the right tool for that job.
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.
SQL is an excellent tool for a data warehouse, or any situation where there is value in separating data design from application design. In such situations the infamous o/r impedance mismatch is arguably a good thing.