My own research doesn't back up that this "unsafe write" was done by 10gen for benchmarking reasons, but rather due to an early expected use case (from a footnote in part 1 of my series):

Waiting for writes was off by default:

> This "unchecked" type of write is just supposed to be for stuff like analytics or sensor data, when you're getting a zillion a second and don't really care [if] some get lost [or] if the server crashes.

This was rarely the typical use case in most startups - even though the defaults were based on it for a long time.

It’s unclear to me how long this was the top Google result, and it was earlier in Mongo’s life (2009). This may be one of the benchmarks that led to anger at competing NoSQL vendors - and seems to me like a mistake rather than a malevolent effort.

https://www.nemil.com/mongo/1.html#fn2

_____________________

MongoDB's CTO has also mentioned that if he could go back and change anything it would be this early default, as his earliest customers valued it - but he quickly realized that it caused issues for others.

(Throughout this series, my goal has been to be tough, but fair to both sides)