Currently, there is a global read/write lock. MongoDB does extensive yielding and tracking of on vs. off disk to mitigate the effects of this. In subsequent versions (2.2) , we'll be lowering the scope of this lock as well.

So only one read at a time?

You can read concurrently, but the write lock will block read locks.

http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...

If you have a lot of writes, this is a KILLER. You need to be very careful here.

Note, even with Read-Slaves, you are STILL blocked, since each write replicates to each Read-Slave, and counts as a blocking-write on that slave while it replicates in.

We dramatically increased application performance when we refactored to remove a lot of little writes for things like caching, and moved them to memcache.

Does this make mongo a bad choice for storing real time statistics?

You always have to benchmark for your own use-case.

This is even more true for mongo than for other databases because mongo doesn't degrade very well; when you overload it with writes it will effectively grind to a halt.

This is documented e.g. in the clustrix benchmark: http://sergei.clustrix.com/2011/01/mongodb-vs-clustrix-compa...

No, a read write lock is a lock designed so that multiple readers can hold the lock, but only a single writer can hold the lock. That way readers know no write is taking place(as many reads as you like can take place), and writers know they have exclusive access.

Yes, but keep in mind that while the write lock is in place, reads are blocked, not just writes.