I admire the work that Aphyr does - though at the end of the day, I need to build systems that work for the problem I'm trying to solve (and I have to choose from real things that are available).
Aerospike isn't the solution to every storage problem, and if you are choosing technology based on marketing material, you're probably going to be disappointed.
These technologies in general are trying to address really hard problems and design and architecture is the art of balancing tradeoffs. Nothing is going to be perfect. Yet.
Isn't it kind of annoying that some technical projects bolster their popularity/ecosystem with very fancy websites and impressive/competitive claims, but to really do your job right you have to throw all that away? The best you can do is try to get a sense from the reports of others who have tried something (and may or may not have been rigorous in their evaluation) so you can pick good candidates to even put through trials. (so again, thanks Aphyr)
I came across Aerospike technology via a pre-existing system at a previous employer, and watched that system scale up and perform in a serious way. It wasn't all unicorns and roses all the time as real life never is, but in the context of the real world, it was great. The software is rock solid in a way I've rarely come across, and support was spectacular. (I forget my current production clusters are even running sometimes they are so stable, reliable and self-operating)
And at the end of the day, there was no other solution out there remotely competitive that we could find. And I looked - not because we were dissatisfied, but because that was our fiduciary responsibility to the company, to ensure that we were deploying the most cost-effective systems that met our feature and performance requirements.
Ultimately yes - I think that as an engineer, you need to understand what your tools are really capable of and avoid doing what I call "BDD" (Blog-Driven Design). That isn't the ideal answer - it would be nice to have a reliable understanding of the capabilities of the materials we use to build systems (like civil engineers can reason about materials like steel and concrete in repeatable ways) but what we call "software engineering and architecture" is still a very young discipline, very often with unrealistic expectations about our ability to deliver in given budgetary and temporal constraints, so we do what we can.
These seem like highly detailed Github Issues (infact the recent elasticsearch was a GH issue-turned-blog post), and these issue are brought to attention so that they could be fixed - not to slander the name of the company (and when they are, everyone benefits). IIRC, even after finding these bugs were published he continued to use elasticsearch.
Given how hard these problems are and how difficult they can be to reproduce, these writeups seem to be the most appropriate way to highlight these issues.
That said, if I was an aerospike user I'd be happier knowing this issue exists, someone has debugged it, and supported a detailed report about rather than being called in at 3am and discovering our data is funky.
Those blog posts are also a great at debunking marketing claims.