Too often, we get customers asking us if they should utilize the popular NoSQL Databases such as MongoDB, Cassandra, DynamoDB etc. for their Custom Software Development needs instead of relational databases such as MySQL, SQL Server, PostGreSQL etc.

We always answer the question with, “It depends.” And follow up with another question, “What outcomes are you looking for?”

See, we all know that NoSQL databases are really popular. They are pretty fluid and pretty darn amazing to work with.

You can add data storage capabilities to your apps very rapidly, you can run faster and get tremendous performance gains.

Developers also get serious bragging rights when they build their web or mobile apps with these NoSQL Databases. For real, it happens all the time. “Oh man, check this out, look I built this all in Mongo!” I often hear developers say.

However, NoSQL Databases are not a panacea. 

We start getting really nervous when Custom Software Development companies start calling themselves NERM shops etc.

They’re trying to FORCE a pre-defined technology or a stack for every problem without any care or consideration.

Side note: Be careful of software development companies that are “Ruby shops” or “.NET/C# Shops” or “JavaScript shops.” You’re going to end up with people who think that their technology is the only way to solve every problem.

At HyperTrends, we do not like reductionist philosophies so we don’t even get into a tech stack until we fully understand the problem. Our technology stack moves from  Java/.NET/C# to JavaScript to Golang depending on the need of the hour.

OK, so going back to the NoSQL question.

Just like every other tool in a toolset, if you learn to leverage the right tool at the right place and time, you’ll gain some serious benefits.

You start using something where it doesn’t belong….now you’re asking for trouble. 

“So, when should I use NoSQL?”, you might ask?

When should I use NoSQL Databases?

These helpful hints should guide you to a decent answer:

1. When you’re building a prototype that you need to get through the door as quickly as possible. The ease of building a NoSQL based solution is extremely appealing.
2. When you don’t know what your domain model is going to be like and you want to put something together so you can put it in the hands of customers to solicit feedback. The fluidity of NoSQL will help you make rapid revisions.
3. When you’re under a deadline and you just really need to throw things together for a small sub-system you have to have.
4. When you’re dealing with structured data that doesn’t need too many relationships between data elements. For e.g. BOMs (Bill-Of-Materials), static data, rarely changing data (locales, timezones, geographical, audit trail) are all great fits for NoSQL.
5. When you really want an extremely fast temporary storage solution – A lot of Mobile Apps immediately store data in a NoSQL database to improve performance and a process eventually moves this data into a more permanent solution.
6. When you have materialized data that you want to present in very high-scale scenarios. Compiled statistics, newsfeeds, aggregate reporting data or any read-model data that consolidates multiple different data sets and optimizes reading data are all great examples of when NoSQL databases can tremendously help you.

When should I NOT use a NoSQL Database

On the flip side, here’s when you should NOT be using a NoSQL Database:

1. When your data is inherently relational – A simple rule of thumb is when you find yourself joining with other collections in NoSQL or looking up related data again and again.
2. When you need ACID guarantees. NoSQL databases are highly performant for a reason. They don’t offer many strong ACID guarantees.
3. When you fear data loss – Yes, NoSQL databases have been known to lose data “at random”. Unacknowledged writes or heavy traffic scenarios may cause data to be lost. Be prepared.
4. When you’re working with rookie developers – Yes, this is such a big one that we had to throw this in. NoSQL databases are schema less and that gives less experienced developers a license to do whatever they want. If you’re not careful about this, you’ll find yourself waking up to multiple versions of the same data in the document or poorly structured data elements. These type of problems creep up in NoSQL Databases largely because the databases don’t penalize you for making such poor decisions.

So there you go. That should at least give you a solid idea on when to use NoSQL Databases. Reach out to us if you have any questions or want us to review your Database Architectures. We will be happy to help.