After mentioning Mozilla Raindrop as a CouchDB case study and using it in an informed comparison of CouchDB and MongoDB, I’m filing this one under lessons learned:

• CouchDB isn’t central to this architecture, but that’s probably good for Couch’s reputation — we were misusing it, and causing it to behave poorly. We still think it’s awesome, we just weren’t able to make it work for this use case (lots of writes & reads, only per-user data).
• Specifically, we fell prey to the “ooh, shiny hammer!” effect, and used CouchDB for everything, including storage of temporary variables, as a message queue, and as a state machine of sorts. Given that our ability to understand the performance implications of some of these design decisions is limited, we’re stepping back from innovating on the back-end architecture, and “falling back” to a system that we can profile and optimize more easily.

via: http://groups.google.com/group/raindrop/browse_thread/thread/7486e1697aef522a/c8c59f07d16c534a