After being clued in by Assaf (who wrote Vanity) I have been testing it out for adoption on my site.<p>A/B testing is practically tailor made for a NoSQL solution: you're storing lots of disconnected bits about individual user/test pairs but never querying over a set of them. The load is potentially <i>very</i> write heavy, <i>very</i> spiky, etc -- these sort of things spell trouble for scaling relational databases. However, key/value stores just slurp them up and ask for more. (Additionally, "eventually ACID" works totally fine for this problem: if one of your Redis machines suddenly dies, you might lose a minute's worth of A/B test assignments for a fraction of your userbase. That's just rounding error on your tests, though, and moreover it is evenly distributed rounding error, so you can just handwave it away.)<p>This is why I went with key/value stores for A/Bingo. (Granted, my site only has about 20,000 writes a week for A/B tests so I could have gotten away with doing it in MySQL/ActiveRecord -- heck, I could probably have gotten away doing it with opening a new flat file for every user -- but some of the larger deployments would probably never have happened if I did it that way. It would have had unacceptable performance implications for key pages on their sites.)