My usual use cases for Elastic Search are that we are using APM, Application Performance Monitoring. We are using Real User Monitoring, as a RUM. We mostly are using it for application performance monitoring and troubleshooting in that regard. I think that's the main thing we're using Elastic Search observability for right now. We are considering expanding it also to have some Metric Beats and some other features. When we have more data, we will probably start to try to activate AI within Elastic Search. That's a possibility. The Elastic Search platform that we are using is an on-prem installation. It's not a cloud solution we have. This is because of the criticality and confidentiality of the data we have in Elastic Search.

I don't think there's a specific feature within Elastic Search that I have found the most valuable so far. We are more or less using all the features in one way or the other. Elastic Search has impacted my organization positively as we use it for logging and APM. It's not all systems which are using it yet, but it's gathering momentum because they have more use cases to present to other parts of the organization. They explain how different departments are using it, and then people see that they could also benefit from using it. More departments and their systems start to use Elastic Search as a result.

The documentation for Elastic Search can be challenging if you're not already familiar with the platform. The approach to Elastic Search can be difficult if you haven't been working with it previously. Within the product itself, some features could be more intuitive, where currently you need to know specifically where to find them and how to use them.

I have been working with Elastic Search for more than four years now.

From my perspective, Elastic Search has been very stable. The only thing I'm probably missing is what we call the session replay, some kind of tool within Elastic Search based on the data collected that can make some kind of session replay.

Elastic Search is very scalable. The only issue is some features use a huge amount of storage. You need to be in the forefront to make sure that you have the necessary storage to obtain all the data that you're collecting. They probably have surveillance indicating when storage is running low. The engineering department ensures we have sufficient storage. So far, we don't have any scalability issues regarding hosts sending data or the amount of data we are collecting. The engineering department might say we are over-consuming data, but we haven't received any message saying we have reached the ceiling yet.

I do not often communicate with the technical support of Elastic Search. That's the engineering department's responsibility. If I have an issue, I go to the engineering department, and they have the responsibility to communicate with the supplier of Elastic Search or the producer.

Positive

I work with many technical solutions compared to Elastic Search, specifically on observability. We are also looking into AI, which is in an experimental phase in my area. We haven't chosen any specific technology regarding AI. For Elastic Search as it is now, we are not looking into other technology to replace it. I am a chief consultant in my department, but in this regard, I'm mostly a user. The ones who are responsible for the platform are in another department. My experience with configuring relevant searches within the Elastic Search platform is limited as I don't search much within the platform. If I have specific needs, I reach out to get assistance from specialists because they are more familiarized with the system and know exactly how to search for things. For implementation configuration of the system, they are more capable than I am, as I'm more of a user than an engineer on the platform. I would rate Elastic Search an eight out of ten because there's always room for improvement, though from a functionality and price perspective, it could be considered a ten.

The main use cases for Elastic Search are index building and retrieving information using Elastic Search vector, vector search, and related functionalities. Search is the primary use case.

Computation is very good. The scalability is very good because we have a huge customer database that is searching lots of products, and auto-scaling or load balancing are the prominent features we are using in this.

If we look at the impact on operational efficiency, we can see that decision-making has become much faster due to real-time data and quick responses. We have also implemented many automations, which enhance our processes. For example, when we optimize certain fields to improve search functionality, it yields great results.

I have not explored Elastic Search at the most. Searching from vector DB is available in Elastic Search, and there is one more concept of graph searching or graph database searching. I have not explored it, but if it is not there, that would be an improvement area where Elastic Search can improve.

I have been working with Elastic Search for more than two years.

It is very reliable, and it has no downtime.

I believe it is scalable. Every day, we have thousands of users continuously utilizing the search feature. We haven't encountered any problems so far, and there is the potential for auto-scaling. It is currently a scalable solution.

We have not contacted them yet. So far, we haven't had any need.

Positive

The initial setup is straightforward.

We have a team of developers, so it is internally managed.

We have not calculated the ROI for Elastic Search, but we are a consumer platform where numerous searches are happening, and we are getting very good results from the current infrastructure of Elastic Search. Though the exact numbers or ROI were never calculated, the performance has been beneficial.

It is average compared to other platforms. There isn’t anything particularly special about the pricing. However, the pay-as-you-go model is advantageous for the organization, as we only pay for what we utilize.

We are using AWS for our solutions. In AWS, we are heavily using Redshift and Glue. We focus more on vector searches and boosting the keywords, and all those features we are using heavily. In search, the key parameter that we boost up during indexing is essential.

We self-implement Elastic Search in our e-commerce application. We are not currently doing a regex setup for RAG Playground, but there is a plan to do that. We are more into vector searches when it comes to how effectively the hybrid search capability meets our needs for combining traditional keyword and vector searches.

Regarding the workflow, we are using the API for real-time inference because lots of data is being loaded at real-time on the application, and it is working well for us. 

I can definitely recommend Elastic Search to be used wherever you have consumer search capabilities needed in a large or scalable manner because it is very effective. 

I would rate Elastic Search an eight out of ten.

My main use case is for security, specifically for the SIEM aspect, as I work as a cybersecurity engineer.

We specifically use this system for security-related topics. We have a dedicated environment for Large Language Models (LLMs). We have connected our LLM, but our primary focus remains on security. When we encounter any incidents or need to gather information about connected IPs, we rely on established rules and alerts. We utilize the chat functionality of this LLM to generate queries in Kibana language.

My favorite feature is the ease of use, particularly in how you integrate the agent. I've been using it since version 7, and we're on version 9 now, and I've seen the progress from using Beats to using the agent, making it so simple today to enroll a server with the Elastic Agent. 

Deploying the Elastic Agent internally is relatively straightforward; it only requires a few commands to be run on the server. However, to manage this deployment at scale, we needed to develop a solution using Ansible. This involved creating scripts to install, restart, and uninstall the agent. While I would have preferred if Elastic had provided an official solution for these tasks, they haven't yet developed one that addresses all the necessary aspects. As a result, we've taken it upon ourselves to create these tools internally.

There are two areas in which it could improve. One is the smoother enrollment process for 1,000 or 2,000 servers at the same time, rather than having to develop something internal. 

The second topic is the actual support of YARA rules—it's Y-A-R-A, which is specific for security. As of today, this is not supported, and I've been asking for a while now; I'm unsure if they will ever release it.

I have been using this solution for at least four years.

I haven't seen any downtime.

It is really scalable. Since we're on the cloud, whenever we need to upgrade or add resources, they handle everything. It takes a couple of hours due to the amount of data we have, and I've never faced any issues during upgrades.

I have contacted technical support because we encountered issues when we started using the Elastic integrations, some of which were not finalized on their side. I had countless meetings with engineers from Elastic, including product managers and support engineers, to work on and fix the integrations we wanted to use. They have always been really responsible and responsive to my requests. Once, we had an issue with GCP, Google Cloud Platform, and they even sent us a complimentary five or six hours with an Elastic consultant to help set things up.

I would give them a nine out of ten because they are very responsive. They clearly know what they are talking about. I never encountered a situation where the support team didn’t understand what we needed.

Positive

The initial setup process took around a month.

What they need is to be more transparent about the actual setup of the cluster and the deployment process. When using Elastic out of the box, there is information that is not readily available, requiring users to dig deep into the documentation to truly understand how it works. If you're looking to set up the cluster automatically, it works well for testing purposes. However, when installing two thousand servers at once, if your deployment isn't large enough, it can lead to crashes. Occasionally, we have to delete the logs just to access the interface. Therefore, I believe they should provide clearer guidance on using the deployment manager effectively.

We started four years ago with 200-300 servers, and now we are at around 2,000 servers. The learning curve involved understanding how it works, doing labs, and the difference between Elastic Search and competitors. Elastic really helped with support; we had weekly sessions with engineers from their side to assist us in setting up.

Maintenance on my end is limited to updates. Since we are using Elastic Cloud, they take care of the infrastructure.

I am familiar with the pricing, as we negotiated it last year. Compared to other tools, it's fair. However, if we are talking with full transparency, Elastic pushes clients to buy the Enterprise edition instead of the Premium edition, and we don't see the value in that other than to spend more money more quickly. So, while pricing is good and what we expect to pay for this type of product, I'd love to finalize this concern.

We've tested multiple open-source tools based on Elastic before signing with them, including one tool called Wazuh that is built on top of Elastic. We've also tested the open-source edition of Elasticsearch where we manage the cluster and Splunk. Overall, I believe Elastic Cloud is still one of the best products out there.

I would rate this solution an eight out of ten.

Our main use case for Elastic Search is primarily for application search and document discovery.

We built an application with APIs that make documents available for search to the enterprise and we store the documents as well. A typical flow would be when an upstream application delivers a document to us, and then a different application or different user looking for some documents comes to our application, enters the metadata for that document, which we use to search in Elastic Search to retrieve the document and then deliver that document to the end user.

The seamless scalability is something I see as among the best features Elastic Search offers.

The speed with which Elastic Search is able to search through all of the documents we place into it is quite remarkable, as we search through 65 billion documents in less than a second in most cases, on a constant consistent basis.

I find configuring relevant searches within Elastic Search platform very straightforward. Elastic Search is easily scalable.

The customer support for Elastic Search is quite good.

I advise others looking into using Elastic Search to think about the future of your platform and where you intend it to be in five years, and based on that, which version of Elastic Search best suits the needs of your platform. Additionally, jump into the AI products first as you're in the planning phase so that as you're filling out your data, the AI products and machine learning products can enrich the data real-time early on in the process, which will save you a lot of time later.

The overall performance of the platform, scalability of the platform and other additional features, especially when it comes to AI, really earn the nine.

The ability to change field types seamlessly would be a huge improvement for Elastic Search, and more seamless upgrades would also be a big improvement, especially with regards to upgrading between major versions.

The upgrade experience and inflexibility with fields keeps Elastic Search from being a perfect 10.

I have been using Elastic Search the whole time I have been at Optum since 2019.

Elastic Search is stable.

The customer support for Elastic Search is quite good.

I would rate the customer support a nine.

Positive

We previously used a self-hosted Elastic running on virtual machines, and we switched to Elastic Cloud on Kubernetes at the urging of Elastic Search itself, as well as an internal drive towards cloud-first technologies. The features of Elastic Search Cloud on Kubernetes seemed to mesh well with the overall goals of our organization.

My experience with pricing, setup cost, and licensing for Elastic Search is overall fairly straightforward.

I do not have any specific numbers on a return on investment, but I do have a general sense of the overall improvement of efficiency of the platform as we moved from on-prem hosted to Elastic Cloud on Kubernetes, where the time saved from maintaining the platform itself was significant.

My experience with pricing, setup cost, and licensing for Elastic Search is overall fairly straightforward.

We have tried the hybrid search capability, and we have seen overall fairly positive results, though we have yet to roll it out in production.

We have implemented a proof of concept using Inference APIs in our processes, but we have yet to release it into production.

To be clear, we are not on Elastic Cloud serverless; we are on Elastic Cloud on Kubernetes, running on the Azure platform self-hosted.

We have not utilized Better Binary Quantization, BBQ, in our operations.

On a scale of one to ten, I rate Elastic Search a nine out of ten.

My main use case for Elastic Cloud (Elasticsearch Service) is to capture logs from our various systems.

For our cloud service, we have various Elastic agents that ship logs into a central location. We have it all aggregated in our Elastic Cloud. From there, we use the logs for troubleshooting, creating alerts, look for specific patterns, understanding our service a little bit better, and aggregating all that data in one place.

One of the better features of Elastic Cloud (Elasticsearch Service) is Lucene Search, which gives our users the ability to search through the mountains of logs without giving them direct access to production systems.

Another great feature is Index Lifecycle Management that allows us to move data to cheaper storage tiers as our data ages out. The feature that we love the best is LogsDB, which allows us to index our data differently so that it doesn't accumulate as much storage in our hot tier and allows us to ship many of those logs, especially older logs to cheaper storage such as S3.

Elastic Cloud (Elasticsearch Service) has positively impacted my organization by allowing us to move away from expensive services such as DataDog and gives us about the same level of service while allowing us to keep data for a longer period of time at a cheaper price.

The logging feature of Elastic Cloud (Elasticsearch Service) itself is pretty valuable, but we tried the observability module and some of the AI features.

Those need improvement. Observability is not on par with feature and ease of use with some of the leading providers out there. The same applies to some of the AI features within Elastic Cloud.

I have been using Elastic Cloud (Elasticsearch Service) for five years now.

Elastic Cloud (Elasticsearch Service) is stable.

Elastic Cloud (Elasticsearch Service) is very scalable and very easy; we've had no issues with scaling our solution out.

The customer support for Elastic Cloud (Elasticsearch Service) is fantastic. They're very responsive, and gave us great detail in all our tickets.

I would rate the customer support as 10 out of 10. They are very knowledgeable.

Positive

I previously used DataDog. We switched because DataDog was too expensive, especially when it comes to logging.

It was very quick and easy to set up. The hard part for us was taking out the metrics and observability because it wasn't relevant for us.

The ROI for this has been positive.  We have seen a return of 30-40% in lower costs and improved productivity.  

Teams are more productive because they have a level of self-service to research problems without accessing production systems, which they previously did not have the ability to do.

Previously, accessing logs was complicated, but now everything is centralized. This has boosted productivity for our support teams, and both engineers and other staff can quickly view service logs and troubleshoot issues in a timely manner.

Before choosing Elastic Cloud (Elasticsearch Service), we evaluated other options, such as Grafana Loki, and Observability.io.  We found that Elastic matched what we needed the most.

LogsDB has made the biggest difference for our team because Elastic can get expensive as your data grows. Our teams want to view data back 30, 60, 90 days and with LogsDB, it allows us to be able to capture that data for a longer period of time and without the expense.

The advice I would give others looking into using Elastic Cloud (Elasticsearch Service) is to identify your pain point and find the tool that your users are familiar with.

For us, it was logging, and Elastic was perfect for that. Our users were very familiar with Lucene Search and the Lucene Search syntax, which made Elastic the ideal option for us. There are other solutions out there that are more multi-service, but Elastic does logging the best.

Elastic Cloud (Elasticsearch Service) really saves your organization money. You don't need the folks on the back end to manage it and support it on a daily basis. 

On a scale of one to ten, I rate Elastic Cloud (Elasticsearch Service) a nine.

We use Elastic Search for search purposes and things related to semantic search.

It is not being used for the moment regarding my main use case for Elastic Search.

In my experience, the best features Elastic Search offers are its stability and brand new features that I consider very interesting.

The machine learning features of Elastic Search are very interesting, including the possibility to include models such as ELSER and different multilingual models that let us fine-tune our searches and use them in our search projects.

The machine learning features of Elastic Search have helped us with many things such as improving our searches and experience for the guests.

We could benefit from refining the machine learning models that we currently use in Elastic Search, along with the possibility to integrate agents, intelligent artificial intelligence, form of agent, and MCP.

It would be useful to include an assistant into Kibana for recommendations, advice, tutorials, or things that can help improve my daily work with Elastic Search.

I have been using Elastic Search and Kibana for about four years.

In my experience, Elastic Search is quite stable.

The scalability of Elastic Search is very good in my opinion. It never has incidents that cause issues in our daily tasks.

The customer support for Elastic Search is one of the best I have ever tried. Whenever I had to create a new incident, I got the responses that I needed.

Positive

I consider Elastic Search a very good project. On a scale of 1-10, I would give it a 10.

The features and capabilities that Elastic Search provides are very easy to use, and the documentation is rich. You can find and understand everything here to use it properly.

I would tell others looking into using Elastic Search that they can try it and see if it fits their use cases.

Elastic Search is a very good product. I really appreciate all the features that it provides, and I hope this product continues its evolution in the way it has been.

At Shopee, I worked with numerous database schemas to find out which table columns belonged to which schema. We utilized Elastic Search to manage metadata for millions of tables, allowing us to search efficiently. Besides that, we used Logstash to put all the log files in Elastic Search for easy searchability.

Elastic Search significantly improved my work. Previously, when searching for text that appears in the middle of strings, the process was time-consuming. Elastic Search enables efficient searching, enhancing system performance and responsiveness. I can also collect logs through Kafka, send them to Elastic Search, and create indices, thus managing logs and customizing searches easily.

Elastic Search provides features such as stemming and range-based queries to search log files efficiently. It allows filtering data easily by searching for specific words based on created indexes. This made searches very efficient, and it also allows for log collection through Kafka and helps with managing logs and customizing searches according to needs, such as grouping by dates or user IDs.

Elastic Search could improve in areas such as search criteria and query processes, as search times were longer prior to implementing Elastic Search. Elastic Search has limitations for handling huge amounts of data and updates, especially if updates are frequent. It doesn't handle big data scale efficiently, especially regarding data size and scale, compared to Apache Solr. It doesn't support real-time search effectively, as it refreshes the indexes every few seconds.

It is stable as many companies already use Elastic Search. In cloud scenarios, it manages well by scaling up or down based on peak traffic. Otherwise, similar functionality needs to be replicated in a private cloud, including backups.

Elastic Search requires enhancements for handling huge amounts of data and updates. Segmenting or sharding data and complexities regarding the cluster can be issues. Updating in Elastic Search involves index computations and user dependencies. There might be issues regarding data size and scaling, but these can be tuned and improved.

I remember Apache Solr, which is generally used for much larger scale data compared to Elastic Search. Apache Solr is used by most companies, and while Elastic Search is very common, there are technologies similar to Elastic Search, though I'm not familiar with all the names.

I have used Elastic Search, but I might not be aware of many internal details; I just used the API to create an index, manage data, and search. It's very useful. On a scale of 1-10, I rate it an eight.

The main use case for Elastic Search is mainly for log management.

I appreciate the indexing capabilities and the speed of indexing in their product, which demonstrates how quickly logs are collected and stored. The search capabilities are also valuable.

The architecture of Elastic Search could be improved as it is complicated for most general users to build up the environment and maintain the cluster.

Currently, I do not have suggestions for additional functions that could be added to the product.

I have been working with Elastic Search for about two years.

I usually use Elastic Search on-premises, which introduces complexity in deployment. Using the cloud version would reduce the complexity of setting up.

I would rate the stability for Elastic Search as eight out of ten.

I would rate the scalability as eight.

I would rate technical support from Elastic Search as three out of ten.

The main issue is a general sum of all factors. Being based in Hong Kong means I can only assess the service in my region and cannot speak for other regions based on my experience.

Negative

I am currently working with multiple solutions including Elastic Search, Splunk, and Graylog.

The initial setup for Elastic Search is complex.

The real-time analytics capabilities depend on whether you use the paid version or open-source version.

I work with SME users of Elastic Search, though the solution can technically support enterprise customers.

I have not extensively used AI technology with Elastic Search.

I can recommend Elastic Search to other users.

The pricing for Elastic Search rates as four out of ten. Overall, I would rate Elastic Search as seven out of ten.

The full text search capabilities in Elastic Search have proven to be extremely valuable for our operations.

Regarding AI integration, we have not yet implemented any AI-driven projects or initiatives using Elastic Search.

I am currently working with Elastic Search as the primary solution.

My role is Senior DevOps engineer at UVIK Digital.

On a scale of 1 to 10, with 10 being the highest, I would rate Elastic Search as an 8 overall as a product and solution.