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.
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...
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.
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.
Yeah. This was a configuration error. Keys you just rotate. Making repos private accidentally creates a whole new mess with forks, stars,... Not recommended
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
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 )
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).
> 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?