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.....
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.