Unlike the attempt to picture things, the idea of non SQL based databases exists for many years.
The thing is, that sure SQL based databases are important, but they are not the only means to use. You need to better understand your needs before you choose the proper way to store and retrieve data. "NoSQL" is not the answer for life, universe and everything (that's 42), but it's another way to look at your data.
It's not always possible to use the same structure to handle data. Sometimes your data structure is way too simple to use SQL, Sometimes it's too complicated for SQL to handle, and sometimes, it just does not matter.
The idea is to understand the way you require to handle data. For each type of requirement, there is a different penalty that you'll have to pay, in order to have what you wish for. There is no magic, no voodoo or anything else, for every solution. There is a penalty at some point, in order to provide you the answer for the requirements you surfaced.
SQL based databases are usually more reliable way to store data, but they are slower in many ways.
The New types of "NoSQL", are suited for the buzz world of "cloud computing" (aka grid computing), but they return fast with "good" answer, even when something went wrong. The thing you must understand is that they usually queue your request, and handle it later on. It makes you work fast, but you must be less reliable on your data, until you can validate it. It's good when you need to provide multiple requests per seconds, but as you can understand, that's a big price to pay.
The Old style of "SQL", is usually more ACID based. Each action is validated when it executed, and returned to you. It's slower but more reliable with it's answer.
There are in-between databases as well. There are "NoSQL" based databases that are full ACID, and return with the proper answer, and "SQL" databases that are not full ACID and return valid answer that might not be valid when it actually executed.
The thing is, that you must understand and know what, when, and where to choose. The boundaries are not so easy to set on many cases. If you have to provide the user a lot of information, then that's one path to take. But if you have a lot of write and updates, that's another path you should choose
The design of your data, and the way you work, also have effect on how to choose your tool.
So instead of ignoring hypes or joining them, remember, that "Yes SQL" and "No SQL" are two different sides of the same coin. And sometimes you must choose both of them for the same project.