Real-time monitoring for Liquibase database changes is here!

RDBMS vs NoSQL: Picking the right tool for the job

August 16, 2017
RDBMS vs NoSQL: Picking the right tool for the job

When I’m working around my house, I carry my tools in a 5-gallon bucket. Before starting my job, I’ll place the tools and hardware I think I’ll need in the bucket and then move onto the job. Often and sadly, I find that I have not gotten the right tool. Now, I’m faced with a question: do I attempt to use my sub-optimal existing tools or walk back to the garage and get the right tool?

Always, always go get the right tool. By the time you figure out how to accomplish your task with the wrong tool, you would have already fixed the problem if you get up, walk over to the right tool, come back and use the right tool.

Of course, software isn’t a tool. It changes, improves, sometimes backslides…but it is not static. So, when companies start evaluating NoSQL databases, specifically document stores like MongoDB and CouchDB, they need to make sure they are doing so for the right reasons. Do they have the wrong tool? Is it worth the walk back to the garage?

Let’s be super clear here: You should use an RDBMS for your application because NoSQL databases are not a panacea. And, to aid in the maintenance of clarity I’m going to bullet point the arguments for NoSQL document stores and explain why they don’t pass muster.

JSON is easier for programmers

Easier than what? Walking a result set to display the values? Maybe it is. However, there is no way a MongoDB query is “better” than a SQL Query. Bottom line: mere mortals can more easily read, understand and explain a SQL query.

Here’s the MongoDB one:

db.users.find({
  “signup_time”: {
    $gt: new Date(Date.now() – 24*60*60 * 1000)
  }
})

And here’s the SQL version:

SELECT  *
FROM    users
WHERE   signup_time >= CURDATE() – INTERVAL 1 DAY

NoSQL Scales Better

That’s the Costco argument. “Look at this deal on 2 gallons of sour cream.” You will never use it all as it will go bad before you do. Or that could be the late 90’s dot-com argument that drove up Sun’s stock. “I better buy all these Sun servers because I’m going to have as much traffic as Yahoo!” (Well, Yahoo! was big back then.)

Agile has taught us that we don’t solve all our problems first. We tackle the immediate ones first. Moreover, you’re using a Microservice architecture, right? So, if you start to run into scalability issues due to the data store, then update that one microservice — If you aren’t using a Microservice architecture, you’ve really should be looking at that instead of your data store for scalability relief.

Ok, ok… But I really like JSON as a datatype.

Me, too! And guess what, so does MySQL, SQL Server, PostgreSQL, Oracle, the rest. The RDBMS implementation of the JSON datatype that can also be referenced as a table is AMAZING! Best of both worlds, I think.

So, shard off your monolithic database into smaller shards tied to Microservices. Go to the cloud. Start putting JSON into your RDBMS.

But, don’t move to an entirely new platform for the wrong reasons. You can get there from here and go through RDBMS land.

To learn more about DevOps Tools for the Database read our white paper, Four DevOps Tools You Can’t Live Without