xeraa

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.

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 ;)

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?

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.

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.

Well, it was a bad change. But we wouldn't want the wrong story make it worse. It was "just" an error in our configuration.

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]

8 years ago someone accidentally deleted the elasticsearch repository (thinking it was their private fork ). Back then everything was restored, so I hope we get there again this time too

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]

Permissions aren't the problem. But the upstream source of all the forks is wrong if you take a repo private, all stars from folks outside your organization are gone,... So you need GitHub support to restore everything.

And the details how it happened are a bit different but it was a configuration error (making things too secure )

[I work for Elastic]

GitHub support can (and currently is) restore all of that. The fork network should already be fixed for Elasticsearch again

[I work for Elastic]

Yes, we don't have that competitive clause — it's Hashicorp [I work for Elastic]

We did: https://www.elastic.co/blog/elastic-and-amazon-reach-agreeme...

But it takes a long time. And it's very costly (especially against a much larger entity like Amazon). Legal battles alone will rarely save you (in time).

[I work for Elastic]

> You can now execute Elasticsearch-compatible insert and replace JSON queries, which enables the use of Manticore with tools such as Logstash and Filebeat

Looking at the docs I could only see _create and _doc but not _bulk endpoint support. How will that work with Logstash and Filebeat?

Elasticsearch in later versions has done quite a lot in terms of memory reduction. Last section of https://www.elastic.co/blog/three-ways-improved-elasticsearc... but it has been an ongoing effort in multiple of the later 7.x and and 8.x releases.

In Elasticsearch, the default has changed more than 3 years ago (since we always ship the current JDK by default): https://github.com/elastic/elasticsearch/pull/49123

Both for DEB and RPM the packages are coming from our own registry (https://artifacts.elastic.co) and not from the Linux distributions. We also maintain our own Docker registry (and mirror that to Docker Hub though they provide some numbers). So we have a good picture about licenses, versions, operating systems,...

Philipp from Elastic.

The license change to the dual-license with SSPL and Elastic License hasn't happened — this is the state so far and all the code outside the `x-pack` folder is Apache v2 licensed.

Going forward the repository will have a dual-license and the top image on https://www.elastic.co/pricing/faq/licensing can hopefully explain that better.

[Disclaimer: I work for Elastic]