It turns out the reason it was the right choice was that Mongo is quite traditional. It relies on you having a middle tier where your app logic resides. Couch is more radical and it not only replaces the traditional database but also the middle tier. If, as we did on this particular project, you already have a middle tier then using Couch adds complexity to the solution. Some of the app functionality ends up in the mid-tier and some in Couch. With Mongo you keep doing what you were doing. Query result processing and Map Reduce functions are all defined within the Java, Python, etc. code. When we needed a data import script the logic was all in the script and not split between script and database.
But there’s another way to see it: CouchDB keeps data processing code closer to the data — data and code collocation.
Original title and link: Some observations on MongoDB & CouchDB (NoSQL databases © myNoSQL)