Actually, Joins are Easy in MongoDB.

> People forget, no matter how much optimization you do, joins are slow - and it is for exactly this reason that Mongo is fast, with usually 5ms response times.

Yes, joins can be slow, but that's not the reason that Mongo is fast. The presence of a join feature doesn't slow down a database, just its use. Seems like just more anti-SQL FUD.

> At least with Mongo you are in explicit control of the speed of your database.

I don't see how Mongo gives you any more control in this respect -- joins are totally optional in a SQL DB.

Because the whole point of a join is that it's on the server, not the client. In other words, if we need to retrieve 10,000 rows from table A joined to B, the join to B will add only a tiny speed penalty, because the data's all right there, ideally in memory.

But if the server has to send all 10,000 rows back to the client, who then has to send a second request back to the server for rows that match any of 10,000 ID's, that's horribly inefficient and not really a join at all!

For merges which can be done in parallel I assume? For example:

    SELECT * FROM a
    JOIN b ON b.id = a.b_id
    JOIN c ON c.id = b.c_id
    WHERE a.foo = "bar";

You cannot query b until you know all b_ids from a (unless you materialize all of b clientside which obviously performs terribly on non-trivial datasets).

Likewise you cannot query c until until you have the set of c_ids from bs (which as stated before are dependent upon the results of a).

An RDBMS can merge JOINs as it goes but to simulate that you'd have to do 1 query against b for every record streamed back from the a query. That also will scale terribly for non-trivial datasets.

As far as I can tell there are no docs for this feature, and the post lacks any technical details.