Sigh. These kinds of tests, and I use this term in this case, usually break from the very beginning. MySQL is not a "slower" database than MongoDB. One is a relational database, the other is a NoSQL document repository. They will / should be faster in the functional areas that they were intended to cover. In the case of MySQL (or any DBMS) and MongoDB, this overlap is not as great as many people think it is. This is the same broken apple and comparison of oranges that you get with Radish and MongoDB discussions.
There are so many variables (application functional requirements, hardware resources, concurrency, configuration, scalability, etc.) to consider that any benchmark or article that ends with “MongoDB faster than MySQL” or vice versa summarizes the results to the point of futility.
If you want to do a test, first define a strict set of functional requirements and business rules, and then implement them as efficiently as possible for both solution and preservation. The result will be that one is faster than the other, and in almost all cases a faster approach has some significant drawbacks that can make a slower solution more viable depending on requirements.
All this ignores the fact that the above test does not simulate any real-world scenario. There will not be many applications occupying the maximum throughput without any streams / concurrency (which significantly affects the performance of most storage solutions).
Finally, comparing inserts like this is a bit broken. MongoDB can achieve stunning insert throughput with fire and forget volume insertions, or it can be several orders of magnitude slower with synchronized replicated recording. The fact is that MongoDB offers you a choice where MySQL is not (or less). Thus, the comparison here only makes sense of business requirements that allow you to record fire and forget recordings (which boils down to “I hope this works, but not great if it’s not”)
TL; DR stops making simple bandwidth benchmarks. They are almost always useless.
Remon van Vliet
source share