You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

noSQL vs Relational DB

There are a billion articles on this, but having read half of them, I’d like to vomit what I’ve taken away as important from them.

Relational databases are integral to any software developer. We’ve been working with them since day 1 of our career. Now comes mongoDB and the appengine Datastore, and there is a ton of hype behind it. But what are the actual benefits?

The big thing you lose with noSQL is joins. If you’re not doing joins noSQL will probably outperform a relational db. So if you don’t need reporting, if there’s no complexity needed for the data, noSQL is actually a fine solution. That’s not to say you can’t do joins. They’re just different and much slower to perform. So you end up with a bunch of data redundancy, which makes changes to that redundant data much more difficult, but eh, if that data barely ever changes, it ain’t no thang.

Another thing you lose that are the constraints on data, foreign keys, data type constraints. All of that has to be handled in the application layer. Which it should be anyway, but having a second line of defense for validation is nice. We all tend to think in terms of objects. Set objects with clear constraints, so having things set from the get go is understandable. The gain of data amorphism, I haven’t really been able to imagine a real world situation where that’s an actual plus.. which could be due to lack of imagination because that’s what I’ve done forever.

The big thing you gain with noSQL is ‘elastic scaling’. When a relational db starts to get huge, the db gets bigger. The single server that’s running the db has to be bigger and badder, and all replication has to be just as big. With noSQL, you can break up the data between servers. This is especially useful in the cloud, and when trying to cut costs in general. 5 small-medium servers can be dirt cheap compared to 1 huge server.