> 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.<p>I think this is the most significant factor, by far. With Mongo it's turtles (or at least Maps/Hashes) all the way down, without a strange pseudo-english layer near the bottom that forces you to translate back and forth. For some devs that's a big deal.<p>For the last while I've been experimenting with bringing the same feature to PostgreSQL (<a href="http://bedquiltdb.github.io" rel="nofollow">http://bedquiltdb.github.io</a>), turns out it's very do-able, but I don't have enough time to make it as featureful as it needs to be.
"So while MongoDB today may not be a great database, I think there's a good chance that the MongoDB of 5 or 10 years from now truly will be."<p>Either MongoDB will be, or other databases that have learned the lessons, both good and bad, of MongoDB.<p>RethinkDB appears to have captured the "MongoDB done right" mindshare, and PostgreSQL has gained JSON and is gaining better replication in order to cover the same niches.
Counting arguments very carefully? Nearly every SQL library does this for you.<p><pre><code> cur.execute("INSERT INTO a (b,c) VALUES (%(a)s, %(b)s);",
{ 'a' : a, 'b' : b })
</code></pre>
Also, SQL is typed, so even if you did fail to count arguments there is a good chance you'd just detect it the first time you ran it.<p>The article acts as if treating the DB like native structures is somehow innovative and new - it's not. <a href="https://en.wikipedia.org/wiki/Object_database" rel="nofollow">https://en.wikipedia.org/wiki/Object_database</a><p>We mostly abandoned object databases because they sucked. SQL was a huge improvement over them. SQL is a great way to organize and preserve the integrity of a lot of business data.<p>It's also a fantastic way to avoid repeated trips to the DB:<p><pre><code> SELECT * FROM employees AS e
WHERE e.department_id = (SELECT id FROM departments WHERE name = "engineering");
</code></pre>
In Mongo, I'm pretty sure you need to first lookup engineering, then lookup the employees in engineering. That could be O(# employees in engineering) queries rather than 1.
I don't understand the recent backlash against NoSQL here.<p>First off, almost all of the complaints would have been valid years ago. Secondly, there is so much more choice out there today if mongodb wasn't the right answer for your project, and so many NoSQL stores have had time to mature and get polished APIs and docs.<p>We use various data stores for different purpose across microservices, mostly ES, couchbase, and datomic, and "use the right tool for the job" and "do one thing and do it well" feels like the right approach to take. For most applications, a SQL DB feels like a really big hammer that is put to a lot of things that don't look like nails.
Just a note that in PG'OCaml (an OCaml interface to PostgreSQL), you <i>can</i> write:<p><pre><code> "insert into foo (col1,col2,col3) values ($a, $b, $c)"
</code></pre>
and it creates the safe prepared statement with ? placeholders. At compile time. Type-checked against the database to make sure your program types match your column types.<p><a href="http://pgocaml.forge.ocamlcore.org/" rel="nofollow">http://pgocaml.forge.ocamlcore.org/</a>
I agree that the three areas outlined in the article are things that MongoDB got right: a structured query language (instead of a textual query language), replica sets, and the oplog.<p>But the lack of transactions over multiple documents (in the same shard at least) and the lack of joins over multiple collections are a big showstopper for the kind of applications I develop.<p>I note that solutions like YouTube's Vitess provide something similar to MongoDB's replica sets.<p>I also note that PostgreSQL's logical decoding provide the same functionality than MongoDB's oplog tailing.
> 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.<p>Author nearly lost me here with this logic. Placing Marketing ahead of quality in something that is supposed to store a <i>very</i> valuable asset (data) is near insanity.<p>I get the mindset of "break fast", "release often", etc. in terms of customer facing <i>features</i>, but in something that is supposed to be a core part of your foundation, stability is if utmost importance. Otherwise nothing else works - and you lose customers, business, opportunities - because you can't look them up later.<p>Its not "brilliant marketing", its just marketing.
I have to agree with the author, especially since the points he raises are the ones that helped me greatly on my first "serious" personal project[1].<p>Coming from postgresql land I would have never thought you can have such great replication with automatic failover. I've had literally 100% uptime for the past year.<p>And that's on commodity servers (one of them being in a room in my apartment, the other two in a proper datacenter) going through the usual upgrades, downtime, reboots, going from mongo 2 to mongo 3 and such.<p>Speaking of which, the migration from mongo2 to mongo3 was another pleasant surprise: they've made it backwards compatible. So I could do the upgrade on the servers, one by one, checking everything was ok and after that I could focus on updating the drivers and rewriting the deprecated queries, no need to have everything ready at once.<p>The accessible oplog was another gem that fit my project really well. Gone was the need to poll the database, I could just "watch" the oplog. That, coupled with long polling on the browser side meant I'd have very little chatter between the db/server/web client when idle. Websockets would have been nice, but adoption wasn't high enough that I'd be comfortable going forward with it.<p>And all this considering MongoDB was my first NoSQL experience.<p>I agree it doesn't fit every project, but when it does, it's a really nice experience.<p>[1] <a href="https://graticule.link/" rel="nofollow">https://graticule.link/</a>
RethinkDB took all the good parts of MongoDB and added proper engineering.<p><a href="https://www.rethinkdb.com/" rel="nofollow">https://www.rethinkdb.com/</a>
I love the point about the Oplog.<p>There are a few equivalents for common SQL DBs (see LinkedIn's Databus for Oracle and MySQL), but in general, getting access to the write log is really hard. Even though it's sitting there!<p>It would be wonderful if there were some kind of established API or library that would let you parse the MySQL write log without doing hideous, fragile operations that change from version to version. Sure, change the format, but at least version and document it!
When we chose MongoDB for a project, a dominant criterion was out of the box geo queries. It helped that the storage and query approach had good impedance match with NodeJS. From a query perspective, we wouldn't have benefited much from SQL anyway, since much of the reading is free text or social graph or location based search which we moved to Solr.
It becomes much simpler to setup replication in PostgreSQL than before.<p>reference: <a href="https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps" rel="nofollow">https://www.digitalocean.com/community/tutorials/how-to-set-...</a>