Funny argument on the query languages in hindsight, since the latest release (https://www.paradedb.com/blog/paradedb-0-20-0 but that was after this blog) just completely changed the API. To be seen how many different API versions you get if you make it to 15 years ;)

PS: I've worked at Elastic for a long time, so it is fun to see the arguments for a young product.

There are no 2-node clusters (it needs a quorum). If your setup has 2-node clusters, someone is doing this horribly wrong.

First step of a marketing campaign: Claim something never said and then tell everyone why it's wrong ;)

It's not so much that Elastic is saying it as a lot of people doing the supposed wrong the advert-article describes.

I've seen some examples of people using ES as a database, which I'd advise against for pretty much the reasons TFA brings up, unless I can get by on just a YAGNI reasoning.

It will also depend a lot on the type of data: Logs are an easy yes. Something that required multi-document transactions (unless you're able to structure it differently) is a harder tradeoff. Though loss of ACKed documents shouldn't really be a thing any more.

The clear misrepresentation for years with absolutely no shame...

No more hacks — Elasticsearch just shipped native joins in ES|QL. Yep, actual lookup joins, across indices, with a real query language, and real performance. This is big for logs, metrics, security data — basically everything you’ve been force-denormalizing for years. It only took 15 years...

What do you want to see? Elasticsearch backed by a blob-store like MinIO?

Yeah, that is exactly what I'm looking for

Elasticsearch just hit its 15-year milestone! A look back at the last 15 years of indexing and searching, and turn to the next 15 years of relevance.

It's a configuration error (sorry!). Also with thousands of forks this would be a pretty pointless operation. Once something is out (and that includes a license), you cannot just take it back — it will be there forever.

[I work for Elastic]

Yeah. This was a configuration error. Keys you just rotate. Making repos private accidentally creates a whole new mess with forks, stars,... Not recommended

[I work for Elastic]

No need to spread rumours: It was a configuration error. GitHub support is helping with restoring everything, since the fork network, stars,... are otherwise all off.

And if you leak credentials, you'd just have to rotate them. Taking the repo offline would probably be too late anyway and causes a major mess, so not something I could recommend for popular repos

[I work for Elastic]

It would be a "rumour" if I had stated that it was the truth. If it's not the right explanation then fine, but I see no need for defensiveness. I mentioned that possibility not to criticise elastic, but because it's a security property of GitHub that very much violates the principle of least surprise and that I suspect of causing a security problem for at least one of my previous employers. Well worth spreading awareness IMO.

A: "I'm betting..." B: "Could be, or maybe..." — once you reach E it's probably a statement. That sounds almost like the definition of how to start a rumor...

Since we don't maintain private forks for the Elasticsearch repository (maybe for someone's short lived feature development), the problem of private or deleted forks shouldn't be an issue here.