"Generally, we find MongoDB to be a very good fit for building web infrastructure."<p>I strongly agree. I just went through a painful transition of our product from CouchDB onto MongoDB. It was a week or two of pain, but I had things isolated enough that it didn't hurt as badly as it could have.<p>Fundamentally, Couch was a pretty amazing piece of technology, and Damien Katz is coder's coder. But they want to make something that would act like a Lotus Notes client. I wanted a piece of web infrastructure.
I didn't know about the stale attribute for couchdb(mentioned in a comment in the article). I can see places where it will speed up things in our set up.<p>Also, Mongo DB is interesting and I have plans to evaluate it for our setup(batch reads and writes, no master-master replication requirement, but need master-slave replication, also need sharding rather desperately). Does anyone have any experience couchdb-lounge mentioned in the same comment?
MongoDB appears to memory map its data: <a href="http://blog.mongodb.org/post/137788967/32-bit-limitations" rel="nofollow">http://blog.mongodb.org/post/137788967/32-bit-limitations</a><p>This is fine on 64-bit CPUs, but less good on 32-bit dev boxes that people are probably using.<p>Very nice API, though.
"Mongo uses (auto) sharding as our path to scalabity (sharding is in alpha)"<p>it's my understanding that mongo currently only shards primary key lookups, not queries. it'll be interesting to see how successful they are in grafting a full distributed layer over top of it. generally the merge layer kills you because you must query all nodes to support global indexes. that is not to say that its impossible.<p>mongo has some wacky stuff in the on-disk file format which is kind of interesting, too.
CouchDB seems to be kind of a weird and interesting beast. I feel like it's what you'd get if you optimized completely for elegance and didn't consider pragmatism.<p>When I look at the design I feel somewhat inspired, but not, exactly, to replicate it. It's odd.