Any detailed and specific reasons for Why MongoDB is much faster than SQL DBs?

First, let's compare apples with apples: Reads and writes with MongoDB are like single reads and writes by primary key on a table with no non-clustered indexes in an RDBMS.

So lets benchmark exactly that: http://mysqlha.blogspot.de/2010/09/mysql-versus-mongodb-yet-another-silly.html

And it turns out, the speed difference in a fair comparison of exactly the same primitive operation is not big. In fact, MySQL is slightly faster. I'd say, they are equivalent.

Why? Because actually, both systems are doing similar things in this particular benchmark. Returning a single row, searched by primary key, is actually not that much work. It is a very fast operation. I suspect that cross-process communication overheads are a big part of it.

My guess is, that the more tuned code in MySQL outweighs the slightly less systematic overheads of MongoDB (no logical locks and probably some other small things).

This leads to an interesting conclusion: You can use MySQL like a document database and get excellent performance out of it.

If the interviewer said: "We don't care about documents or styles, we just need a much faster database, do you think we should use MySQL or MongoDB?", what would I answer?

I'd recommend to disregard performance for a moment and look at the relative strength of the two systems. Things like scaling (way up) and replication come to mind for MongoDB. For MySQL, there are a lot more features like rich queries, concurrency models, better tooling and maturity and lots more.

Basically, you can trade features for performance. Are willing to do that? That is a choice that cannot be made generally. If you opt for performance at any cost, consider tuning MySQL first before adding another technology.

Here is what happens when a client retrieves a single row/document by primary key. I'll annotate the differences between both systems:

1. Client builds a binary command (same)
2. Client sends it over TCP (same)
3. Server parses the command (same)
4. Server accesses query plan from cache (SQL only, not MongoDB, not HandlerSocket)
5. Server asks B-Tree component to access the row (same)
6. Server takes a physical readonly-lock on the B-Tree path leading to the row (same)
7. Server takes a logical lock on the row (SQL only, not MongoDB, not HandlerSocket)
8. Server serializes the row and sends it over TCP (same)
9. Client deserializes it (same)

There are only two additional steps for typical SQL-bases RDBMS'es. That's why there isn't really a difference.

In general, MySQL and MongoDB are quite similar in "durable" write performance on a single machine. Simple key/value lookups are almost the same... if you want to use MySQL that way. Document support is, obviously, a big productivity benefit and a big win for performance.

With automatic sharding... MongoDB is faster in indescribable ways. Out of the box, with proper design, you can scale out almost linearly without building any logic into your code whatsoever.

Read/write splitting is also built into almost every driver... which, most, are sponsored or developed by 10gen themselves.

I've scaled applications before and written read/write splitting code, distributed hashes for sharding, rebalancing jobs running continuously, and added gzip to mysql "document" stores. ugh.

It's faster because it's simple and focused. It's designed with all of this in mind. Scale on commodity hardware is a priority. The priorities of a RDBMS are quite different.

by default, mongo doesn't do any indexing; there are also no transactions. however, if you configure a mysql table to be un-indexed, and turn on autocommit, you won't see a huge speed difference. writing bits to disk just takes a certain amount of time.

however, mongo is designed to easily scale. using shards, you can horizontally scale your writes and get much better performance without the complexity of master-master replication. using replica sets, you can scale your reads horizontally. so, i would say that there's a systemic performance improvement, but each query is not necessarily faster.