SoylentNews

Phoenix666 [soylentnews.org] writes:

MongoDB is perhaps the most-widely-mocked piece of software out there right now [nelhage.com].

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.
...
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.
...
Structured Operation Format
...
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.
...
Replica Sets
...
MongoDB's replica sets are not without their warts, but the conceptual model is fundamentally strong, and allows operators to, with minimal fussing, configure read replicas, manually or automatically fail over to a new server, add or remove replicas, and monitor replication health, via simple, standard interfaces, all with minimal or no downtime, and almost entirely using in-band administrative commands (no editing of configuration files or command-line options).
...
The Oplog
...
Rather than define a new serialization format for changes, the oplog reuses BSON, like everything else in MongoDB. In addition, the structure of BSON entries is quite simple – there are only five or so types of operations. The conjunction of these two features makes it easy to parse and interpret oplog entries.

The combination of all these features means that it's feasible – even easy – to use the oplog not just as an internal implementation detail, but as an application-visible log of all database writes, which can be used to drive external systems, such as data analysis pipelines or backup systems.

Original Submission