We got some very frank advice from some people whose opinions on databases I take very seriously to stay away, including reports from within FB.
Having said that, I cannot claim to have firsthand proven or disproven anything about Cassandra.
There are a few people (YC companies even, alas) who are very vocally negative about Cassandra, but I also saw some of those same people ignoring direct advice given to them in #cassandra on IRC, and then turning around and bashing it when it didn't work as planned. Simply following the advice could have made for a completely different story.
I suppose the lesson to learn is that you need to develop software in a way that simply won't allow developers to shoot themselves in the foot, because people never want to blame themselves for doing it, they blame the gun.
At large loads and footprints, imvho, Riak, Cassandra and HBase present viable options. But there are some factors to consider that don't seem to get mentioned in the pop tech press
- What are you able to operate in production?
- What are you able/willing to debug and patch?
- What hardware options do you have?
- What are your workloads?
- Which variable of C.A.P, when you lose it, most damages your business?
- Will your company's choices be evaluated in the press?
- Does your board/investors have capital tied up in business's that are using something else?
- What architecture tradeoffs and styles sit well with you?
- What kind of data access and consumption patterns make you money?
- Can you pay for help?
The right choice is context sensitive, and I'm fairly sure for this class of systems at this point in time, there's no free lunch. That means you have to do the legwork for yourself and make your own choices and commitments; doing what you heard worked for someone else is a cargo cult.