I took me 3 months or so to finally grok CouchDB map/reduce queries. Now that I've seen the light, I'm not sure I'll go back to an RDBMS any time soon -- at le

I took me 3 months or so to finally grok CouchDB map/reduce queries. Now that I've seen the light, I'm not sure I'll go back to an RDBMS any time soon -- at least not for bread and butter webdev. "...You must know what will be the questions that you will be asking upfront." Even in SQL land you need to know your queries in advance. Sure you can do table scans on unindexed fields, but you're going to crush i/o. With Couch you can always deploy new views during a maintenance window for queries you didn't anticipate. Same thing with adding indexes in an RDBMS to handle unanticipated/slow queries. At least with Couch I know that my queries are more-or-less pre-computed in B-trees. I know I'm not scanning the same tables over and over. Moreover, if you know what you're doing wrapping conflict handling around Couch's MVCC is straightforward.. and you get all the benefits of offline replication. In my case, I've built a service that calculates utility-style usage based off Couch range queries that are reduced into a cost calculation. Given any date range I can reduce a utility fee an order of magnitude faster than I could in SQL land. YMMV, etc.. but I'd say this is a case of "haters gonna hate".