a) Depends if you run with replication and how you've configured your writeconcern (w and j values). https://docs.mongodb.com/manual/reference/write-concern/#ac

a) Depends if you run with replication and how you've configured your writeconcern (w and j values). https://docs.mongodb.com/manual/reference/write-concern/#acknowledgment-behavior https://docs.mongodb.com/manual/reference/write-concern/#ack... This is giving you the choice where in the CAP triangle you want to be. As you can see the default of w:1 and j:null when run in non replicated mode does not write journal to disk before ack. If you want better guarantees read some best-practice articles, most of them recommend w: majority, especially when run in replication. c) no issue d) $lookup works fine and is as old as 3.2, but as with any join, if you try to combine 2 tables with millions of rows each, performance will be bad. That said it's not as good as RDBMS here. No foreign keys or voodoo under the hood optimizations for example. Mongodb sales people will always say that you should model your data differently, without really giving good examples of such. But really - even if multi document queries exist, you should not continue modeling data as BCNF and think of mongo as a drop in replacement for RDBS, the domain should be suited for denormalized documents to begin with.