MongoDBは悪だ。なぜならそれは…
- …データを無くす（ソース：1、2）。
- …実際、長期間、デフォルトでエラーを無視し続け、何があってもすべての単一書き込みが成功したとみなした（ 32ビットのシステムで3GBかそこらを使用したら、MongoDBの制限によって何の警告もなしに全データを失うことになった）。
- …宣伝していたユースケースでですら遅く、これが早いと主張するには完全に証拠に欠けている（ソース：3、4）。
- …ほぼ全てのユースケースで、暗黙のスキーマという悪しき習慣を強要してくる（ソース：4）。
- …ロッキングに問題がある（ソース：4）。
- …セキュリティの問題になるくらい、応答時間が酷く遅い。求めてきた人全員に認証なしで全データをさらしてしまうという危険なデフォルト設定をパッチするのに2****年かかった（ソース：5）。
- …ACID特性に準拠していない（ソース：6）。
- …拡張やメンテナンスをするのが大変すぎる。
- …提供するJSONベースのストレージにおいても排他的でない。PostgreSQLも同様に提供しているし、CouchDBなど他の（もっと良い）ドキュメントストアも昔からある（ソース：7、8）。 …つまり現実的には、MongoDBが得意とするところは何もなくて、あるのは明らかに不得意なことばかりだ。そしてここまで箇条書きにしてきた内容は全て事実で、「あなただけの意見」ではない。他のサイトを見て自分で確かめてきてもいい。
ほとんどの場合、本当に必要なのはリレーショナル・データベースだ。この場合、PostgreSQLはとても良い選択肢で、クエリビルダやORMを使えば、より作業が捗る。Node.jsでは、Knex（クエリビルダとして）、Bookshelf、Sequelize、Waterline（ORMとして）などがある。
あなたのプロジェクトが、ユーザアカウント、または2レコード間の関係が関与してくるものであれば、最終的にデータはリレーショナルになるため、ドキュメントストアではなくリレーショナル・データベースを使うべきだ。
もし自分がMongooseを使っていることに気づいたなら、リレーショナル・データベースも使っていて然るべきだ。Mongooseのようなライブラリは、ドキュメントストアを使ったスキーマフルなリレーショナル・データベースを（下手に）エミュレートしようとしているだけなので、最初からリレーショナル・データベースを使ったほうがよさそうだ！
たとえドキュメントストアが必要だとしても（もう一度言うが、ほとんどのケースで必要ではない）、MongoDBより有用な選択肢はたくさんある。ここにドキュメントストアデータベースのリストがある。注意してほしいのは、このリストは_人気_順になっていて、データベースのクオリティについては触れていない。
**決して、「みんなが使っているから」という理由でデータベースを使ってはならない。人気のデータベースの長所と短所を自分で調べること。**人気というのは広告によるところが大きいし、優れたマーケティングチームの手にかかれば、凡庸なソリューションでも世に広めるのは難しいことではない。
そして、「プロトタイピングに良い」というのもまた違う。結局は満足に製品化もできないようなデータベースで自分自身をがんじがらめにしてしまうのがオチだ。あなたのプロトタイプが実行可能そうなら、違うデータベースを使って_全部_書き換えなければならなくなるだろう。
現在のほぼ全ての開発におけるエコシステムには、ロールバックを伴うマイグレーションがある。それは、プロトタイプとして同等の使い勝手の良さを提供してくれるもので、本番用コードを書き直さなければならないという欠点はない。
MongoDBには有効なユースケースがない。MongoDBは、他の選択肢に比べて技術的に劣っていて、実際に_使える_機能もこれといって提供していない。開発者たちは、データベースにとってほぼ最重要とも言える、データの整合性とセキュリティを守ることができないのだ。
原文：http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/ (2016-2-18) ※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。
あとがき
プロダクション環境で運用したことが無く実際に困らされたわけではないので、大きな期待を持って現れた MongoDB が今ではオチ担当のような扱いを受ける現状に不憫だなと思う昨今……（得意とするところは何もないとまで言わなくても）。 技術を選定する時は、不得意な領域や罠を事前に把握して、自分たちのニーズに合ってるかを的確に判断しないといけないですね。
