HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
elastic
elasticsearch
Java2010–2024
elastic / elasticsearch

elasticsearch

Free and Open Source, Distributed, RESTful Search Engine

Systems & InfrastructureSearch & Information Retrieval
Explore on GitHubRead Hacker News discussions
74Distinct people
88Mentions
0Explicit recommenders
78.7KGitHub stars
REPOSITORY AT A GLANCE

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

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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.

0510152010-01-01 00:00:00 UTC to 2011-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20102011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 8 mentions; 2 submissions, 6 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 15 mentions; 1 submissions, 14 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 14 mentions; 0 submissions, 14 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20102010-01-01 00:00:00 UTC2011-01-01 00:00:00 UTC101
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC000
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC101
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC817
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC808
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC826
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC413
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC15114
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC10010
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC14014
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC808
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC707
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC110

What Hacker News says

88 sources
nikonyrh·Oct 18, 2023
Oh interesting, I thought this was going to be a .gitignore file we could use in all projects :D Do you have any thoughts on rather than listing all the file extensions you don't want to track: - https://github.com/tensorflow/tensorflow/blob/master/.gitign... - https://github.com/redis/redis/blob/unstable/.gitignore - https://github.com/elastic/elasticsearch/blob/main/.gitignor... You'd list the file extensions you want to track? Here is an example for a PHP project: * !/ !.php !.md !.xml !.gitignore !composer.json Or Clojure: * !/ !.clj !*.md target/ !.gitignore If you have exceptions on these rules, you can always force-add the files or add the extension to .gitignore, to configure it not being ignored.
In One .gitignore to rule them all
manquer·Sep 17, 2023
What are you on about ? https://github.com/elastic/elasticsearch https://github.com/mongodb/mongo How are ES and mongoDB not open source ? Mongo switched from GPL v3 to SSPL in 2018 the only difference is whether you can offer mongoDB as a service , all other GPL clauses are the same , there is no difference for app developers I.e no vendor lock-in Elastic moved from Apache 2 to ESL v2 for the same reasons with same restrictions against managed offerings again no restrictions for a app developer to host modify or do they want . Redis splits between 3-BSD , SSPL and RSAL v2 and closed source for redis , Redis stack and Redis enterprise. Just cause OSI does not consider restrictions on competing with the author Open source doesn’t make elastic or mongo less open source ( redis also uses these ) certainly not for anyone not a cloud vendor
In Unity’s new pricing: A wake-up call on the importance of open source
buro9·Jan 24, 2023
Benchmarks are always "It depends". And what it depends on are your data volume, how you want to query, whether you value ingestion greater than query speed and timeliness and so forth. Elastic sweet spot is that it indexes everything, and you can query fast as a result. But it does this at the cost of ingest as it's doing the work to build indexes during ingestion and so ingest is more CPU intensive and can hit limits here. As a general purpose workhorse, Elastic shines. Loki sweet spot is that it has very few indexes, so ingestion is cheap and extremely capable for huge data volumes. It does this at the cost of query performance over very large data sets - without indexes queries brute force via mapreduce, which means you really want to specify where to look (which log streams) and when to look (a time window) and in that it excels. For
Read the rest
logs, Loki is heaven. ClickHouse sweet spot is the indexes (columns) are very explicitly configured by engineers who know what the data looks like and how they want to query it. Now the ingest cost is balanced, and the query performance is great - but it did this at the cost of you knowing your data and how you're going to query it most of the time - it's not so good for esoteric questions that you'd never anticipated (though you can get very far through some of their column data types allowing you to be reasonably flexible on this). For BI data, ClickHouse is incredible. They all have sweet spots, and a benchmark is not going to answer the real questions - what data volume do you have, what do you value (ingest and preserve everything vs fastest query speed for ad-hoc queries vs a balanced approach), do you know how you want to query the data, etc? Other thoughts: Loki has recently moved to TSDB for the backend storage, these benchmarks don't go there. Elastic can use less disk if you configure for synthetic source (https://github.com/elastic/elasticsearch/issues/86603) which discards the raw byte copy of the ingested data and only retains knowledge in the indexes, and uses the indexes to reconstruct the source should you request it. Enabling this is only supported by ES for metric type data (according to docs) but it is possible to enable it for other types of data. Nothing to add about ClickHouse, I've used all three databases and worked against all three for huge volumes of data - if I want a more OLAP style querying than OLTP and I know my data then today ClickHouse absolutely shines here with the others playing catch up. Elastic and Loki shine far more for OLTP workloads, so it's a trade-off again (though Elastic does a good job at doing pretty well for more OLAP cases than Loki does today due to it having column storage - and Loki wins on being able to ingest more cheaply - meaning being able to ingest more at the same or lower cost). What you value and what you want to do is up to you.
In Elastic, Loki and SigNoz – A Perf Benchmark of Open-Source Logging Platforms
francoismassot·Sep 22, 2022
(disclaimer: I'm one of the cofounder of Quickwit.io, we are doing log search) (edited to add vector search category and add manticore) When looking at OSS search projects, it's nice to have a rough ideas of the different use cases, here is the list I have in mind: - user facing search (think algolia): elasticsearch[1]/opensearch[2], meilisearch[3], typesense[4] - enterprise search: elasticsearch/opensearch - log search: elasticsearch/opensearch, loki[5], quickwit[6], zincsearch[7] - vector search: Milvus[8], Qdrant[9], Vald[10] Weaviate[11] Vespa.ai[12] is great but I don't really know in which category to put them, user facing and enterprise search seems to work well with them. It's interesting to note that Elasticsearch and Opensearch are general purpose search engine, Solr as well. They are all powered by Lucene, the popular and per
Read the rest
formant search engine library. Another general purpose search engine is Manticore search[13]. I would love to see some benchmarks by category :) Note: I don't know well ZincSearch and put it in the log search as said on their front page. [1]: https://github.com/elastic/elasticsearch [2]: https://github.com/opensearch-project/OpenSearch [3]: https://github.com/meilisearch/meilisearch/ [4]: https://github.com/typesense/typesense [5]: https://github.com/grafana/loki [6]: https://github.com/quickwit-oss/quickwit [7]: https://github.com/zinclabs/zinc [8]: https://github.com/milvus-io/milvus [9]: https://github.com/qdrant/qdrant [10]: https://github.com/vdaas/vald [11]: https://github.com/semi-technologies/weaviate [12]: https://github.com/vespa-engine/vespa [13]: https://github.com/manticoresoftware/manticoresearch
In ZincSearch – lightweight alternative to Elasticsearch written in Go
SemanticStrengh·May 27, 2022
I hate the fact that OpenSearch divide in a bipartite the human resources allocated at improving elasticsearch, which is a tragedy. The hypocrisy is strong at amazon, they have allocated a lot of engineers on OpenSearch and yet their number of contributions pre-fork drama was much much lower (although they were still an important contributor though). But once the management has control and developers can have their own NIH dopamine release, humans are eager to work.. For this human resources reasons, I hope the OpenSearch distraction dies in darkness. However, beside my utilitaristic goals, I am also one of the only person caring about the technology. And it happens that the technology is generally not found in ElasticSearch but in the much more salient project: Lucene, which it uses. However, despite its big humans resources, ElasticSear
Read the rest
ch does a great job at NOT exposing Lucene features and optimizations... Lucene especially has developped 2 major optimizations the last decade unexposed in ES, one being about shards (don't recall the name), the other being concurrent search. And it happens that the NIH syndrome at amazon allow them to at least reconsider those frozen choices in ES. https://github.com/opensearch-project/OpenSearch/pull/1500 And I am eager to see the performance implications it will have although the ES approach has some pros too. In this issue, I descibe what ElasticSearch would do for parallelism, in an ideal world: https://github.com/elastic/elasticsearch/issues/80693
In OpenSearch 2.0
_msw_·Feb 18, 2022
Disclosure: I work for AWS. There were contributions sent upstream for Elasticsearch bugfixes and enhancements. Some of those PRs are still open, for example [1]. A sampling of additional PRs can be found in this blog post [2]. Further contributions upstream to Apache Lucene have been growing over the years. The new Approximate Nearest Neighbor support in Elasticsearch 8.0 comes from work that was sponsored by Amazon in upstream Apache Lucene [3]. [1] https://github.com/elastic/elasticsearch/pull/64513 [2] https://aws.amazon.com/blogs/opensource/stepping-up-for-a-tr... [3] https://issues.apache.org/jira/browse/LUCENE-9004
In Elastic and Amazon reach agreement on trademark infringement lawsuit
joshxyz·Feb 4, 2022
Awesome. I've tried MeiliSearch and it is very easy to set up and use. It works very well for less than a million of data. The only let down for me is their very slow indexing speed when it comes to millions to tens of millions of data (personal experience, also experienced by other users in their public slack workspace). Other competitors / alternatives: - https://github.com/typesense/typesense - https://github.com/quickwit-oss/quickwit - https://github.com/elastic/elasticsearch - https://github.com/valeriansaliou/sonic A decent feature-by-feature comparison: - https://typesense.org/typesense-vs-algolia-vs-elasticsearch-... If you guys know other open-source competitors / alternatives, I'd love to check those out!
In Meilisearch raises a $5M Seed to change the world of user-facing search

Showing the 15 most recent of 88 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.