I've evaluated almost all of the "NoSQL" databases out there (excluding graph databases) and have settled on riak-search as the solution for my startups infrastructure.<p>I've been on the painful side of scaling more than once, and while I'm not planning to be bigger than facebook, I am not going to buy the world of operational hurt I have experienced in the past. Especially given that avoiding it actually saves me time and money.<p>At least with Riak-Search it does. Riak is a dynamo style document store / key-value database and in that regard it benefits from all notes being of a homogenous type. The thing that hurts most key-value stores is finding documents based on what they contain, and the integration of indexes (inspired by lucene, and seemingly compatible with their APIs, though I don't care about that) makes RiakSearch the winner for me. This allows for amazing power when combined with the built in map-reduce, and their flexible API.<p>I really want to emphasize the operational issue for me. My experiences have left me with a prejudice against any system that has more than one type of node. In riak the cluster is all homogenous nodes. No masters, no slaves, no bottlenecks. I love that scaling Riak means simply cloning another machine, and pointing it at the existing cluster, and all the machines spread the load out a bit more. That's the kind of operational story you want for a tiny startup.<p>FWIW, I also liked what cloudant has done with couchdb, and they are adding search features too, so that's worth checking out.<p>Further, we're working on several initiatives all in the same area. Most will likely produce small amounts of traffic, but when we get it right, we're going to tap into a flood. With Riak, all of these apps will be backed by the same cluster, so it doesn't matter which one happens to hit it right. I won't have to build a custom configuration or scale one particular database for the particular app that works. (This is part of our iterative process for finding product-market fit.) What matters is the total capacity of the whole cluster, and we can add nodes, and when there's enough replication, bring down a node and replace it with a bigger box... without having to shuffle data around or worry. The data just gets redistributed around the cluster to accommodate the loss or gain in capacity. The backup story is straightforward as well.<p>It may sound like I'm going on and on about this one feature, but easy, and brainless and automatic means it is harder for me to screw up and that lets me sleep well at night. We'll be starting tiny with a trio of cheap dedicated machines of low capacity at low cost. If we need to grow, we can do so economically, and I expect Riak will scale probably father than we will. This means I don't have to worry about architecture and I don't have to worry about operations, I just worry about the business and the product. That's a savings of two worries!<p>Basho is also the home to seemingly all the erlang action these days (outside of the couchdb scene)... webmachine lives there, rebar lives there, erlang-js lives there. Even the developer of nitrogen (I think) works there. And erlang is most def the right tool for the job. If your project wants to be distributed and it isn't written in erlang, you gotta have some good reasons, I think. (or be using something more exotic and more purpose built than erlang.)<p>I'll close with one final thing- Riak is so well engineered, and they have added so much value, that they have sucked a lot of the hard work out of the apps we're building. They really are providing a fairly complete platform to build on. Besides RiakSearch we're using webmachine, erlang-js & rebar.<p>Frankly, I don't mind seeing people go on about cassandra or mongodb... it just makes me feel like riak is my secret weapon that gives me a significant competitive advantage. Basho's products boost my leverage significantly.<p>What more could a startup engineer want?<p>Anyway, glad to hear Basho is able to raise the cash, and best wishes to the whole crew there.