10 years later, any details I could offer would be relatively suspect; my memory is pretty poor. Still, I'll make an attempt. Don't write a book based on anything below.
I can honestly say it's the best job I ever had, working with the smartest collection of people (I've been fortunate to work at multiple startups, and while Ian Murdock put together a solid crew at Progeny, Basho was just chock full of brilliant people).
Riak was designed for rock solid, massive scale data. The problem was that most companies didn't really need that, and by the time someone reached that size, they had a significant investment in databases that were much more developer-friendly.
We attempted to make it easier to work with by introducing CRDTs, so developers wouldn't necessarily have to write as much application logic to handle conflicts.
Still, it's hard to sell a database when you can't demonstrate simple queries, because your choices were primarily "update static views as you add new data so you don't actually have to run queries in real-time" or "write map-reduce logic in Erlang".
And, it was hard to simulate massive scale databases, so while our resilience and operations stories were pretty good, it was challenging to anticipate how, and where, performance might start breaking down.
I miss it dearly, but I was also lucky enough to never be on a support call when someone was trying to rescue a failing cluster that served millions of customers.
I will say that Erlang made that last scenario much more manageable: the ability to connect to a live node and see exactly what was happening, and the ability to hot patch a function on the fly, was incredibly helpful.
I can honestly say it's the best job I ever had, working with the smartest collection of people (I've been fortunate to work at multiple startups, and while Ian Murdock put together a solid crew at Progeny, Basho was just chock full of brilliant people).
Riak was designed for rock solid, massive scale data. The problem was that most companies didn't really need that, and by the time someone reached that size, they had a significant investment in databases that were much more developer-friendly.
We attempted to make it easier to work with by introducing CRDTs, so developers wouldn't necessarily have to write as much application logic to handle conflicts.
Still, it's hard to sell a database when you can't demonstrate simple queries, because your choices were primarily "update static views as you add new data so you don't actually have to run queries in real-time" or "write map-reduce logic in Erlang".
And, it was hard to simulate massive scale databases, so while our resilience and operations stories were pretty good, it was challenging to anticipate how, and where, performance might start breaking down.
I miss it dearly, but I was also lucky enough to never be on a support call when someone was trying to rescue a failing cluster that served millions of customers.
I will say that Erlang made that last scenario much more manageable: the ability to connect to a live node and see exactly what was happening, and the ability to hot patch a function on the fly, was incredibly helpful.