tl;dr: There's a new "BI Connector" which will allow you to connect your business intelligence tools to MongoDB using the Postgres wire protocol (which many speak). This is somehow bad because Postgres is also popular, and maybe people will use Postgres now. Also: the author (who has a competing connector) knows the names of a lot of people at MongoDB.
tl;dr 2.0:<p>1) MongoDB Inc have made a "foreign data wrapper" for PostgreSQL which enables MongoDB databases to be accessed from within PostgreSQL.<p>2) This makes data in MongoDB databases accessible to existing analytics software for SQL databases, which is often made by companies with lots of money.<p>3) The CTO of SlamData Inc, which makes analytics software for NoSQL databases, thinks that MongoDB Inc shouldn't have done that.<p>tl;dr 3.0:<p>A company faces increased competition; isn't happy about it.
Frankly, if I were tasked with integrating existing BI tools with MongoDB, I'd immediately start looking at ways to "escape" the anemic Mongo ecosystem to something a bit richer. A Postgres FDW seems like an excellent design.<p>Of course, I'm a bit of a Postgres partisan, and a Mongo refugee, but it still seems like a solid engineering decision and most of this guys arguments seem to hinge on "BUT POSTGRES IS TEH ENEMY!".
It's nothing new that PostgreSQL is a great tool for doing analytics, even coming from MongoDB. I'm very happy that MongoDB took this route, it speaks a lot about their capabilities in the non-OLTP world.<p>Having said that, I very biasedly say that there's a much better solution to this connector, which doesn't flatten out the MongoDB data: it's called ToroDB (<a href="https://github.com/torodb/torodb" rel="nofollow">https://github.com/torodb/torodb</a>).<p>ToroDB, open source, speaks the MongoDB protocol, transforms documents to relational tables (without any kind of flattening, and without having to define any schema) and stores data in a RDBMS. More precisely, PostgreSQL.<p>Current development version (repl branch) speaks the replication protocol, and hence can replicate live from a MongoDB into PostgreSQL. No connector needed, no flattening, no FDWs, nothing else. Just add a new "slave" (ToroDB) to your replica set and you're good to go.<p>It goes even further: if you want pure data warehousing, ToroDB will soon support GreenPlum. Some initial benchmarks (<a href="http://www.slideshare.net/8kdata/torodb-scaling-postgresql-like-mongodb" rel="nofollow">http://www.slideshare.net/8kdata/torodb-scaling-postgresql-l...</a>, slide #42) show 25x-75x improvement between doing aggregate queries in MongoDB and their equivalent queries in GreenPlum's distributed SQL.<p>Now that MongoDB 3.2 ships with PostgreSQL "included", feel free to try ToroDB. It's always better the original :)<p>Note: I am a ToroDB developer.
Classic marketing pitch from a little company that wants to claim it's much more significant than it is:<p>1. Claim a must-have set of requirements that ...
2. ... happen to match its product's feature set ...
3. ... but not its competitors.'<p><a href="http://slamdata.com/whitepapers/characteristics-of-nosql-analytics-systems/" rel="nofollow">http://slamdata.com/whitepapers/characteristics-of-nosql-ana...</a> is presumably the core of the argument.<p>I tend not to pay attention to such claims until the company rephrases them more honestly.<p>That said, a brief discussion of what is really happening is in <a href="http://www.dbms2.com/2015/09/10/mongodb-update/" rel="nofollow">http://www.dbms2.com/2015/09/10/mongodb-update/</a> Would more be better? Sure.
The author tries to paint Mongo as an embarrassingly short-sighted, pseudo-enterprise company that can't share its toys with others.<p>Mongo could refuse this by demonstrating collaboration efforts and solutions with a solution marketplace similar Atlasssian and VMware. On the partner side, cross-selling, cross promotions and collaborative sales/product strategies can reduce conflict and wasted/duplicated/unaligned effort that can lead to sour partner experiences.