OPop03·Oct 25, 2020
I use elastic - https://github.com/elastic/elasticsearch
In Ask HN: Why is no one using local/offline search engines?elastic
elasticsearch
Java2010–2024
elastic / elasticsearch
elasticsearch
Free and Open Source, Distributed, RESTful Search Engine
74Distinct people
88Mentions
0Explicit recommenders
78.7KGitHub stars
What to know before exploring
What it is
Free and Open Source, Distributed, RESTful Search Engine
GitHub
Where it is used
- GitHub — GitHub uses Elasticsearch to power its search services as the core search engine. Source
- anyone — “Anyone.com, a global AI-powered real estate platform, replaced a Postgres search back end it had outgrown with Elasticsearch, moving 210 million production records onto a single index in about a week and a half and consolidating its entire search infrastructure into three lines of Terraform.” Source
- 1 more documented example
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- opensearch-project/opensearch · linked in 3 of the same discussions
- elastic/elasticsearch-formal-models · linked in 2 of the same discussions
- quickwit-oss/quickwit · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:59:58 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year88 dated mentions
Observed mentions: 2010-07-20 20:38:02 UTC to 2024-10-29 14:01:46 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2010 | 2010-01-01 00:00:00 UTC | 2011-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 8 | 2 | 6 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 15 | 1 | 14 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 14 | 0 | 14 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
10 sourceshttps://opendistro.github.io/for-elasticsearch/ is one way to use ES with security without paying
It's just stunningly dumb that one cannot know what version of ES corresponds to the ODFE but it seems to be a pretty modern one (7.8.0): https://github.com/opendistro-for-elasticsearch/opendistro-b... versus the 7.9.1 upstream https://github.com/elastic/elasticsearch/releases
In Microsoft leaks 6.5TB in Bing search data via unsecured Elastic serverYSK that ANN is already in the process of being added to Lucene:
https://github.com/elastic/elasticsearch/issues/42326
A different implementation is already in OpenDistro for Elasticsearch:
https://opendistro.github.io/for-elasticsearch-docs/docs/knn...
In ScaNN: Efficient Vector Similarity Searchnot quite that repo is a mix of https://github.com/elastic/elasticsearch/blob/master/license... and apache 2.0 .. the elastic license stuff is in a particular sub directory, but there's so many intermingled commits, a contributor can't look at git history without becoming tainted. Which then leads to elastic suing folks building on their opensource..
https://www.elastic.co/blog/dear-search-guard-users
https://www.elastic.co/blog/dear-search-guard-users-includin...
In Show HN: Kanmail – An email client that functions like a kanban boardhttps://github.com/elastic/elasticsearch is Apache2, and free as in beer, no?
In Show HN: Kanmail – An email client that functions like a kanban boardSome of my favorites -
Elasticsearch - https://github.com/elastic/elasticsearch
Google's Guava - https://github.com/google/guava
Sourcegraph - https://github.com/sourcegraph/sourcegraph
Spectrum - https://github.com/withspectrum/spectrum
Django - https://github.com/django/django
In What are best examples of well-structured open source products to learn from?Jason from Elastic here.
It is indeed good reading, but as you say, old. Since then, we have invested tremendously in the [data replication][0] and [cluster coordination][1] subsystems, to the point that we have closed the issues that Kyle had opened. We have fixed all known issues related to divergence and lost updates of documents, and now have [formal models of our core algorithms][2]. The remaining issue along these lines is that of [dirty reads][3], which we [document][4] and have plans to address (sorry, no timeline, it's a matter of prioritization). Please do check out our [resiliency status page][5] if you're interested in the following these topics more closely.
Thanks for all of the feedback in this entire thread.
[0]: https://github.com/elastic/elasticsearch/issues/10708
[1]: https://github.com/elastic/elasticsearch/issues/3200
Read the rest
6
[2]: https://github.com/elastic/elasticsearch-formal-models
[3]: https://github.com/elastic/elasticsearch/issues/52400
[4]: https://www.elastic.co/guide/en/elasticsearch/reference/7.6/...
[5]: https://www.elastic.co/guide/en/elasticsearch/resiliency/cur...
Disclaimer: I am an engineer on the Elasticsearch team; I welcome any and all feedback.
Thanks for this info!
Doing a quick googling on elasticsearch and ZGC I just found this https://github.com/elastic/elasticsearch/issues/44321 where the official response from elastic is that only G1GC and CMS are tested and supported.
I still think that it will be worth trying Shenandoah or ZGC if/when we ever get down to do some experiments with larger heaps.
In Guide to running Elasticsearch in production> Yeah, but we already have processes to manage the latter. It's the (potential) buffer overruns that keep me up at night!
I'd _hope_ you'd have those processes, working on space flight and all :P. Good processes > good tools. It's easier to start using a good tool than overhaul your process. So for people who don't have that kind of discipline or heavyweight process, TLA+ gives a lot of benefits for really cheap. AWS, for example, found it really easy to slot into their workflow.
Re buffer overruns, I just remembered OpenComRTOS, which used TLA+ to verify low-level properties of their code.[1] They found it super helpful.
> I'm not saying it never happens (does TLA plus make sure everyone's assuming SI units?), but that hasn't been my experience at all.
'Fraid it probably can't help you with the SI units. I'm thinking about "design bugs"
Read the rest
more like this:
> 1. Suppose we have a document with version 57
> 2. A bulk of delete and reindex will remove the index-v57, increase the version to 58 (for the delete operation), then put a new doc with version 59. While the engine places the index-59 into the version map, the safe-access flag is flipped over (due to a concurrent fresh), the engine won't put that index entry into the version map, but also leave the delete-58 tombstone in the version map. The delete-58 tombstone is stale because the latest version of that document is index-59.
> 3. Another bulk of delete and reindex will increase the version to 59 (for a delete) but won't remove docs from Lucene because of the existing (stale) delete-58 tombstone. The index operation will append document (version 60) to Lucene (instead of overwriting). At this point, we will have two documents with the same id.
Which was a bug TLA+ found in ElasticSearch.[2]
[1]: https://dl.acm.org/doi/10.5555/1779934.1779955
[2]: https://github.com/elastic/elasticsearch/issues/31976#issuec...
Ok, well there's this bug too https://github.com/elastic/elasticsearch/issues/2665
But now you're going to say that's a bug in a specific brain dead server, and it should have been fixed. I'm sure there are other bugs tracking other server's issues with pipelining, but that's the only one I remember seeing (mostly because of the amazingly terrible nature of the bug).
The point of the Bugzilla link is that enabling pipelining in Firefox would trigger bad behavior in servers. It's not some idle fear of unknown problems, it's fear informed by actual problems -- if you turn on the feature mostly things will work fine, but some stuff is going to break, and user interpretation when Firefox gets a broken page and IE (or Chrome, whatever) works, is that it must be Firefox's fault. There's not necessarily a way to detect an error in this case, so
Read the rest
it's hard to gracefully degrade. The exciting world of (mostly) transparent proxies for plaintext http makes this even worse.