Elasticsearch

Elasticsearch is a really scalable solution that can fit a lot of needs, but the bigger and/or those needs become, the more understanding & infrastructure you will need for your instance to be running correctly.
Elasticsearch is not problem-free - you can get yourself in a lot of trouble if you are not following good practices and/or if are not managing the cluster correctly.
Licensing is a big decision point here as Elasticsearch is a middleware component - be sure to read the licensing agreement of the version you want to try before you commit to it.
Same goes for long-term support - be sure to keep yourself in the know for this aspect you may end up stuck with an unpatched version for years.

Elasticseach platform allows implementing a robust operational stuck for unified observability handling a huge volume of data with high performance and capacity to scale fast. Logstash, Beats, and APM products provide a structured framework to collect events and data being easy to deploy and configure.

Elasticsearch is really well suited for searching text (Natural Language Processing) and you can fine tune the searches and scoring very well. I like the ability to find Significant Terms in the Index, where you can find aggregations that are really relevant to a specific search. It also allows for queries to lead to new queries via aggregations which is great for navigating your data. It is less suited to doing more complex aggregations where slices of data are required to be processing using guassian normalizations. And doing searches which join different documents is very very hard, and requires serious thought on how to denormalize data.

Elasticsearch is used very well in the log management space. In conjunction with Logstash, Kibana, and Graylog Elasticsearch makes leveraging these products wonderful. The ease of deploying it. Securing it very quickly. Fast and scalable searching options. It can also be a distributed data warehouse for immutable documents. However, it is not a fully functional database system.

It is well suited for anything involving large data - searching, filtering, aggregations, analytics, reporting, etc.

Elasticsearch is best suited for search, analytics, aggregation, and consumption from single tabular structured data. It works best if you sync your data at regular intervals either with Logstash or any other custom sync process.

Easiest recommendation of my career. The capability and speed are out of this world, and pricing compared to enterprise logging solutions is a fraction of the cost. That'd come with a caveat, that you must be ready to devote some time to it to learn it and get it working. It's not turnkey, but it's one of the best all-around.

I can't speak to paid support, but free support is nonexistent. As is the case with most open-source software stacks. Can't complain though!

Elasticsearch is very well suited within an IT architecture where a lot of open-source software is already being used and where the developers strongly appreciate open-source software. Elasticsearch might be less appropriate in an organisation where there is less space to master the tool. The tool is quite difficult to learn once you start working on the CLI-level search queries.

We've only used it as an opensource tooling. We did not purchase any additional support to roll out the elasticsearch software. When rolling out the application on our platform we've used the documentation which was available online. During our test phases we did not experience any bugs or issues so we did not rely on support at all.

Elasticsearch really excels in search performance, so if you have massive amounts of data you need to search from, Elasticsearch is surely a great fit. I woud advise against using it as the main database or the only source of truth, because data corruption can happen in rare cases, and in that case a reindexing will have to take place.

Elasticsearch support has been great in helping us on the rare occasions when we actually needed help.

Not great for highly structured data where SQL thrives, e.g., heavy use of JOINs. Not great for image data.

I have never used their support, but online documentation was very good.

Elasticsearch is a great tool, but remember as every other tool, needs knowledge and expertise to work with. My first option would be using the cloud version provided by Elastic company, but unfortunately it is over my budget, then I need to manage by myself. Also according to your company's area, it wouldn't be possible to keep your data into third's cloud environment. In this case, there is no option other than keeping it by yourself.

I've never used official support from the company behind Elasticsearch, but I had to get support from community, and being a so known product, it is really easy find someone else facing the same issues you have, and most of time, presenting a good solution for that.

Initially, we were using Elasticsearch for just product searches. It is also becoming useful as our product repository to display all data needed for the product detail pages.

Support has been very good. New releases come out periodically with new features, performance, and stability improvements. Questions to support are answered fairly responsively.

Elasticsearch is so versatile and so easy to set up that it's really a no-brainer including it in most projects as the indexing and search engine components, as well as for analytics and aggregations. It's not so well-suited to be used as the main database, as there's a minor risk of data loss.

Elasticsearch can be used perfectly inside a site for searching features in order to respond quickly to user queries. It can be used to act as a Centralized Log Server, where you can define events based on pattern detection for anomaly detection.
Elasticsearch has potent visualization features with Canvas and OOB Dashboards that can respond to business and technical requirements.

It works well for what we need. Short sharp logs of data from ongoing consistent processes.

Elasticsearch is extremely well suited for structured (faceted) search, full-text search, and analytics workloads. Elasticsearch and the ELK stack are also a good fit for operations teams that want to be able to interrogate their logs in an online (read: fast) query tool. Elastic is amazing at creating super fast search experiences over very large datasets, where traditional RDBMS systems are either too costly or too slow.

Elasticsearch has a very fast an efficient searching process. If you've searched a heavy project, you can't just be dependent on databases. Plus, they have a REST API for everything, making it easy to use with any programming language or database.

If you are in a scenario where you are constantly trying to optimize queries to get better performance from your database searches, Elasticsearch is probably a product worth trying out. With the amount of data we have, doing text searches via SQL isn't even an option. If you aren't struggling with getting reasonably fast queries getting Elasticsearch up probably isn't going to be worth the hassle.

The best situation where we have found elasticsearch to help was when you have searches and your database just isn't doing them with the speed that you want, and even where the DB is going the speed needed Elasticsearch can take some of the processing from the database(which isn't necessarily built specifically for searching) to a system that was designed for searches.

If you are doing searching, then I would suggest going with Elasticsearch.

ElasticSearch is hands down, the absolute best solution for logging in a virtualization environment. The Kibana front end to ElasticSearch is extremely intuitive, even computer novices can be trained on how to chain together tags in the Apache Lucene syntax to extract the data they need. Once the deploy process is nailed down and system is engineered, the logging structure can remain fairly static until the next major revision. Compared to Splunk, with an administrator well versed in the ElasticSearch suite, will save an organization upwards of 10's of thousands of dollars a year even with the caveats mentioned earlier.

As a developer looking for a quick and simple search engine which has little configuration required, ElasticSearch is fast and perfect for that solution. Literally throw JSON records in to the database and push a request to get JSON out, exceptionally straightforward.

Elk is great for app logs and search. It comes with Kibana which is great query tool. Logstash is great. It can autodetect datatype but can be tuned if needed which is awesome. It has lots of integrations such as filesystem, syslog, kafka etc., which make setting it up a breeze. It is also sometimes used for metrics. But [I] would rather use timseries db such as influx db, prometheus for metrics. Using logs for metrics tend to be expensive and inefficient.

I have noticed Elasticsearch is good in following scenarios:
Faster Aggregation
Full-text search features
Scalable
Great performance
Stability
Complete Ecosystems of applications

It could have been slightly better in handling indexing. (Should index all the items and create index overhead)
Better load balancing
Elasticsearch aggregations are not always precise, because of how data in the shards is placed

Elasticsearch is a great choice for search scenarios, for architectures that heavily rely on search capabilities. It's also great for analytics using Kibana. It's also great for log aggregations and again search. It can be even used as the main database layer for critical search infrastructures. But you need to [take] care with data that may change the structure and type of fields.