Retrospective from Postmark on outages (MongoDB)

I know I shouldn't care but I am always weary of doing business with any company using MongoDB.<p>10gen put out claiming MongoDB was so much faster than SQL solutions but it seemed obvious to me than turning off fsync would make the SQL solutions run at about the same speed. Plus, why would I want to run my database in mode where it is easy to lose data? MongoDB may be a useful product but their marketing is deceptive, which will lead to companies using it in inappropriate situations.

I get the impression that one of the biggest issues was missed. They did not test the standard load against the secondary server, they assigned a machine of lower specs to the task and there's nothing in the future actions that indicates they'll change it... Even if they go for the new and shiny, they can end up in the same situation when their master fails.<p>I hope they just overlooked that in the blog post, rather than actually not correcting this first.

Really tried to love Postmark for about 3 months now. Constant, almost daily issues forced us to unfollow them on Twitter (it literally became an annoyance seeing issues daily). Then we switched to Mailgun last week, and we are very happy. +1 to Mailgun

Are they using MongoDB for the wrong purposes? The task they have seems similar to logging and if so aren't there much better software to do that? A logging server perhaps?

So the primary was much beefier than the secondary? If so, why let it fail over? I figured you should always have the same resources for a mongo primary and secondary.

Two is one. One is none.<p>This includes equality in failover systems. The common issue in all of these cases is not the DB engine, OS, stack, whatever, but the infrastructure.