Be careful with benchmarks like this. From having worked a lot with Elasticsearch, I know it requires a bit of tuning and planning to get the most out of it and

Be careful with benchmarks like this. From having worked a lot with Elasticsearch, I know it requires a bit of tuning and planning to get the most out of it and that that is a bit of a dark art for new users. Also, it is very good at querying and aggregation queries and doing that at extreme scale. So statements that X is Y times faster/slower than Z don't mean a lot. How much data are we talking? What kind of mappings, how many nodes, etc. These are apples and oranges comparisons unless you specify this in detail. Several things you might want to look into when using Elasticsearch/Opensearch: - Data streams and index life cycle management policies are crucial for time series data. Basically, with time series data you are mostly querying recent data. So you can benefit from limiting your indices to a size where things fit in memory. Like with any database index, you need that for your queries to perform. Opensearch has a competing feature that does the same thing. Basically with either feature you can ensure your data size does not grow beyond what your cluster can handle. Like with any data base, it doesn't scale to infinity without doing something on the hardware side. - Likewise your mapping matters. Mistake #1 that I see companies make over and over again is to have dynamic mapping turned on in a logging cluster and then every string field both indexed as text and as a keyword. Don't do that. If you are not going to query on it, don't map it. Each additional mapped field consumes resources (memory, disk, IO, CPU). Elasticsearch and opensearch have index templates that you can use and rule based field mappings that you can set up. - Set up your cluster in a sane way. If you are doing tiny amounts of data (a few tens of GB or less), a bog standard 2 or 3 node cluster is fine. I run a couple of logging clusters in essentially the cheapest Elastic Cloud setup that is allowed. Think less than 50-60$ per month. It's fine but it obviously won't scale endlessly. But otherwise, you might want specialized nodes, master nodes, ingest processors, query nodes, elastic scaling, etc. This is a good reason to use Elastic cloud, it comes with some sane, easy to manage options for this and you can easily scale your cluster. If you are not an expert, you will save a lot of time not doing it wrong. - Ingest performance heavily depends on your mapping and how much heavy lifting you make Elasticsearch do at index time vs. how much you do before you send data to elasticsearch. A good ETL pipeline can offload a lot of the overhead to elsewhere. It's completely meaningless to even talk about ingest performance until you've done your homework on that front. Apples and oranges basically. - Elasticsearch uses a lot of internal caching and off heap memory. That's why they recommend using at most 50% of memory for the Java Heap. That other 50% is used for loading blocks of disk into memory and file caching. If that runs out, you are looking at a lot of unnecessary disk IO when you query. So, look at your disk usage and shard, and ram allocation. If those don't line up, things are going to slow down. Nothing against other solutions. IMHO a valid concern with ES is the level of complexity involved with using it properly. Many devops teams are just looking for simple but limited turn key solutions and there are some good options in the market for that. Especially if you don't have data or search specialists on your team, it's worth starting with those.