いくつかの事情があります。
(その1) 関手データモデル： スピヴァックの関手データモデルには色々と刺激を受けました。スピヴァック理論を実際に使ってみたいですよね。関係データベースのほうがスピヴァック理論を適用しやすいでしょうが、僕はもともとXMLのような“文書っぽい”データが好きなので、入れ子と並びを持つデータを直接扱いたいのです。この点では、「ドキュメント指向」を標榜しているMongoDBのほうが向いているでしょう。
(その2) 現実的な要求： データの操作がボトルネックになって困っている状況が実際にあったりします。MongoDBを使ったらパフォーマンスが改善するとも限りませんが（ファイルシステムやSQLiteのほうが速い、とかありそう）、場合によってはMongoDBが解決策を与えてくれるかもしれません。
(その3) Catyのデータベースバックエンド： 「CatyのJSONストレージとクエリ言語」において、「Catyのデータベースバックエンドの候補としてMongoDBを検討しています。」と書いたのは既に2年以上も前です。「唐突に MongoDB の話」とかしたのも、その当時の調査報告（備忘）みたいなものです。時間はたってしまいましたが、気が変わったわけじゃないです。今でも、MongoDBをCatyのプライマリーなデータベースバックエンドにしたいと思ってます。
(その4) 問い合わせと更新： MonboDbに関して、僕がいま興味を惹かれているのは、問い合わせと更新に関する豊富な演算子群です。豊富とはいいながら、アドホックでゴチャゴチャしている印象があります。素材としてはたいへん有用だと思うので、これを使って「使いやすく整合性がある」問い合わせ言語と更新言語を構成したいですね。
(その5) 機は熟したか： 一時、MongoDBに関する悪い評判や不安になる報道がありました。例えば：
- http://www.infoq.com/jp/news/2011/11/MongoDB-Criticism MongoDBの信頼性に疑問 （原文 2011-11-07）
最近でも、
- http://hackingdistributed.com/2013/01/29/mongo-ft/ Broken by Design: MongoDB Fault Tolerance （2013-01-29）
しかし、採用事例は着実に増えているようですし、開発元である10genがインテルとレッドハットから投資を受けたというニュースもあります。
- http://www.publickey1.jp/blog/12/nosqlmongodb.html （2012-11-16）
不安が完全に払拭されたわけじゃないですが、「だいたい大丈夫そう」「開発元も信頼できるだろう」という感触は持てます。今なら、MongoDBを使うのが冒険ってことはないでしょう。
