It seems not too long ago that NoSQL was the hottest thing on the market. MongoDB was leading the charge, with tremendous growth as a company and many developers looking to adopt their platform. I remember years ago going to visit a number of customers in New York City, where Mongo had just grown their offices. Every company was considering migrating their RDBMS to MongoDB, trying to calculate the cost and return.

Now, I certainly hear about companies adopting database that are in the NoSQL family, but not always (or even often) to replace a RDBMS. Instead, it's for a new application or alongside an existing RDBMS. While there are applications that are well suited for a non-RDBMS data store, there are plenty that perform worse on those platforms. This might be because the platform doesn't handle their workload, or because the developers aren't writing good code, but I know I'm not worried that RDBMS usage is going away, or even down.

I ran across an article earlier this year that wonders if NoSQL is a good choice for your application. The article covers a bit of the types of these stores and how they work. It's a basic look, but it makes sense and it addresses the benefits of NoSQL, like scaling. It also notes there are issues, which is something to think about. Not that I see a lot of developers thinking about the issues. Often they think the can code around them.

The piece notes that for some problems, these databases work great. However, for a side project or a simple site, a relational store is likely better. NoSQL classes of databases are suited to scale well, but with quite a few tradeoffs.

Are there places you'd use NoSQL? I'm curious. If your organization has adopted these stores, or rejected them, it would be good to share some information.