masleeds's comments

There are forks being maintained of Riak CS and Riak TS by TI Tokyo - https://github.com/ti-tokyo.

The focus of the OpenRiak community for the moment is on Riak KV only.

I'm not sure though for how much longer it will continue to make sense for the project as-is to continue to roll riak_ensemble forward as part of future releases. As there are no contributors who have direct direct experience or knowledge of using it in production, so it is hard to claim it as being a supported part of the product in any real sense.

I apologise if we do eventually cut it. Having worked through the code when chasing unstable tests, I developed an appreciation for the quality of the work.

When we get stuff together there will be a link from our discussions page - https://github.com/orgs/OpenRiak/discussions.

I would tend to agree, perhaps a decade ago it was easier to define the uniqueness of Riak, and now there are alternatives that offer similar guarantees. So the relevance of Riak is not as obvious.

Also as we focus on stability on OpenRiak going forward, that means reducing some of the capability that may have made Riak stand-out in the scale-out space. The preference going forward is to do fewer things, but do those things predictably well.

There will be differences between Riak and FoundationDB, and I hope those differences are sufficient to make Riak interesting, and allow it to continue to occupy a small niche in the world of databases.

The SOLR part has now been retired from the last few releases.

Current development has been focused on improving the flexibility of secondary indexes. There was some funky stuff achieved by some users using overloaded 2i terms and distributed processing of regular expressions against those terms - the aim is now to make this more flexible to the modern developer using the language of projected attributes and filter expressions (ala DynamoDB). There's also some active work to both replicate-to and full-sync (i.e. reconcile with) external OpenSearch clusters.

The primary goal for OpenRiak is stability under load/failure as a K/V store - so the ultra-flexibility of in-built SOLR querying has been sacrificed in the move towards that aim. Anything that can do harm is to be offloaded or constrained.

Riak has been maintained through the post-basho years by engineers at some of its larger customers (disclaimer - including myself).

The focus has been on trying to improve the stability of the database when subject to complex failure scenarios under stressful load, with minimal need for urgent operator intervention. The focus has been on keeping those existing operators happy rather than seeking out new users. Evolution of the product since basho has been slow but significant.

The project now has support from Erlang Ecosystem Foundation, and we're looking to invest some effort over the next few months explaining what we've done, and to start to articulate what we see as the future for Riak. So if you're interested watch this space.

It is expected to remain a niche product though. However, it may still find a home for those demanding specific non-functional requirements, with an acceptance of some functional constraints.

The claim relates specifically to the spine 2 project, and is as measured over the 5 years since it went live. There are a lot of systems which depend on Spine 2 for their own availability, it is not the sort of thing that can go down at any time without a lot of people noticing.

I'm biased in that I've been heavily involved in the project, but I will stand by the five years of five nines availability claim.