How 10gen’s NoSQL MongoDB is Different Than SQL

I’m part of several different discussion groups where people talk about the tools they use for various projects. One of the questions that’s cropping up more frequently among several of the groups is when using a NoSQL solution makes sense as an alternative to a traditional SQL database like MySQL or Postgres. Like many technology solutions, there’s plenty of disagreement, with relational database fans arguing that you should almost never use a NoSQL solution unless you are planning to store as much data as Facebook.

The group discussions in my world are only the tip of this debatable iceberg. Jeremy Zawodny, who happens to be the author of the original author of High Performance MySQL from O’Reilly, recently wrote a well reasoned post in defense of NoSQL. Jeremy cites built-in features of MongoDB like sharding and replica sets as attractive tools even if you aren’t working with massive amounts of data. His post was responding to Bob Warfield’s claim that NoSQL is a premature optimization.

Who is right? It’s hard to draw a line in the sand and say that anyone with less than N terabytes or Y petabytes should use relational databases. As Zawodny points out in his piece, sometimes there are features that make a compelling solution to your particular problem, even if other factors don’t immediately point to one database over another.

At OSCON 2011, I’ve been talking to a number of people about NoSQL to see if we can get closer to helping people make a more informed choice that isn’t rooted in a holy war. In the video that follows, I talk to Nosh Petigara, 10gen’s Director of Product Strategy, about features of MongoDB, how scaling MongoDB is different than scaling a relational database, and why you might want to use MongoDB at the beginning of your project instead of porting your data after you’ve achieved scale.

LockerGnome coverage of OSCON is sponsored by HP