MongoDB is perhaps the
most–widely–mocked
piece of software out there right now.
While some of the mockery is out-of-date or rooted in
misunderstandings, much of it is well-deserved, and it’s difficult to
disagree that much of MongoDB’s engineering is incredibly simplistic,
inefficient, and immature compared to more-established databases like
PostgreSQL or MySQL.
You can argue, and I would largely agree, that this is
actually part of MongoDB’s brilliant marketing strategy, of
sacrificing engineering quality in order to get to market faster and
build a hype machine, with the idea that the engineering
will follow later.
In this post, however, I want to focus on something different: I want
to explore some design decisions that I believe MongoDB got right,
especially compared to SQL databases, its main competitors1.
Implementations evolve and improve with time, but interfaces last
nearly forever. In each of the cases I explore, I contend that MongoDB
legitimately out-innovated SQL databases, potentially positioning it
– in a few years, once the implementation matures – as a superior
database for a wide range of use cases.
This post is not an exhaustive enumeration: In the interests of space,
I’ve chosen a few areas to focus on, in which I think MongoDB has
really hit on some good ideas. There are a lot of other differences
between MongoDB and a SQL RDBMS; This post shouldn’t be construed as
either a defense of or a criticism of any individual feature or design
choice not listed here.
Structured Operation Format 🔗︎
Let’s start with the simplest one. Making the developer interface to
the database a structured format instead of a textual query language
was a clear win.
SQL is a great language for ad-hoc exploration of data or for building
aggregates over data sets. It’s an absolutely miserable language for
programmatically accessing data.
Querying SQL data involves constructing strings, and then – if you
want to avoid SQL injection – successfully lining up placeholders
between your pile of strings and your programming language. If you
want to insert data, you’ll probably end up constructing the string
(?,?,?,?,?,?,?,?) and counting arguments very carefully.
The situation is sufficiently untenable that it’s rare to write apps
without making use of an ORM or some similar library, creating
additional cognitive overhead to using a SQL database, and creating
painful impedance mismatches.
By using a structured (BSON) interface, MongoDB makes the experience
of programmatically interacting with the database much simpler and
less error-prone2. In a world where databases are more
frequently used as backend implementation details owned by an
application – and thus accessed entirely programmatically – this is
a clear win.
BSON probably wasn’t the best choice, and MongoDB’s implementation
isn’t perfect. But it’s a fundamentally better approach for how we use
d
