NoSQL is about the interface, not the implementation. NoSQL databases provide a better impedance match out of the box for some applications.
What is often lost in the conversation is that you can do the same thing using a competent SQL database engine if you can deal with the complexity. But you have to use SQL, which for some applications is a poor interface, and you have to configure the engine for your application and workload. This adds complexity to the process. If you have great database architects and DBAs, NoSQL does nothing that you can't do on a really good SQL engine. Most startups have neither the people nor money for that.
The vast majority of databases, whether labeled SQL or NoSQL, implement the same relational operator algorithms under the hood. They are not intrinsically different in that regard. Even graph databases, which in theory cannot be expressed in a simple relational algebra, can be and are expressed in practice as recursive relational algebras. As long as databases are using the same algorithms and representations they will have the same limitations.
Most startups also don't have complicated data models or a high enough traffic to justify having a DBA and commit premature optimization by denormalizing data right off the bat to speed up retrieval in your NoSQL DB.
As many have said before, NoSQL is a premature optimization in that all it does is to remove some restrictions in your technology stack to let you move come complexity such as data validation and the ability to easily aggregate data up the stack.
The need for NoSQL is a rich man's problem. When you organize your data like that using the article's techniques, you are going to have to write a lot of very odd looking code and tightly coupled code to do even some basic reporting. E.g when you try to query from the many-to-one direction.
If you are following the Lean Startup methodology at all, you should be aware that being able to measure things is crucial early on when you are trying to reach a business goal. Writing bunch of crazy for loops and map reduce stuff in the application layer isn't exactly easy to write, look at or maintain.
The impedance mismatch is real which anyone who has seen stored procs written by app developers can verify....
What NoSQL does is give you a light-weight object store which could have some very cool uses. Those uses are also pretty narrow for the reasons the article mentions (assuming the questions you have now are all the questions that are important for example).
However, I think some of the solutions may help in relational environments with the edge cases.
That's a little weak as an argument isn't it. SQL and the relational model has nothing to do with stored procedures and you certainly don't have to, or need to use stored procedures for reporting. In fact, prior to 2005, MySQL didn't support stored precedures for the longest time. How do you think those people did reporting? I don't know how you do reporting, but mind involves just a ridiculously simple and ugly web app that essentially just generates some HTML tables from a bunch of SQLAlchemy queries.
Why do I get the sense that the real reason most people use NoSQL stems from their destain of SQL, whatever that reason maybe...
I am a total relational guy, BTW. But the fact is that there is a mismatch between how you have to think when doing SQL queries (thinking in sets) and OO programming (thinking in instructions). Anyone who has dealt with stored procedures written by app folks understands what a mess you get when you try to program one side in techniques aimed at the other.
While NoSQL is a good choice for some environments, namely ones where ad hoc reporting is not likely to be needed and where other methods of interop are preferred (LDAP being a great example of something that could benefit from a NoSQL back-end), the fact is that this actually shows that, more often than not, you lose more than you gain by getting rid of the mismatch....
IOW, I think it is a moderately weak case for NoSQL in some environments and a strong case against in a much larger number of environments.....
What is often lost in the conversation is that you can do the same thing using a competent SQL database engine if you can deal with the complexity. But you have to use SQL, which for some applications is a poor interface, and you have to configure the engine for your application and workload. This adds complexity to the process. If you have great database architects and DBAs, NoSQL does nothing that you can't do on a really good SQL engine. Most startups have neither the people nor money for that.
The vast majority of databases, whether labeled SQL or NoSQL, implement the same relational operator algorithms under the hood. They are not intrinsically different in that regard. Even graph databases, which in theory cannot be expressed in a simple relational algebra, can be and are expressed in practice as recursive relational algebras. As long as databases are using the same algorithms and representations they will have the same limitations.