Elastic Search use cases for us involve maintaining a huge amount of data per day, around millions of transactions for each record. We are maintaining all this data with Elastic, and Elastic is doing a fantastic job by doing the indexing. The algorithm is very good, enabling us to process the data very fast.

We are conducting searches with Elastic Search because the data volume is too high. With a couple of indexing configurations, we are able to achieve our goal.

A good feature of Elastic Search is that they have something called policies, which we can make hot and cold, all related to data retention, and that is what I appreciate the most.

From the UI point of view, we are using most probably Kibana, and I think they can do much better than that. That is something they can fine-tune a little bit, and then it will definitely be a good product.

Maintenance in terms of Elastic is that they can improve the UI and UX, and if they fine-tune it a little bit, then it will be much better.

I have used Elastic Search for the last two years in my career.

So far I haven't noticed any lagging, crashing, or downtime with Elastic Search.

The scalability of Elastic Search is good, and I am satisfied with that as of now, and the performance is good.

I don't think I have ever had to contact technical support.

I find the initial deployment of Elastic Search easy; it is quite straightforward.

Approximately, I am able to deploy Elastic Search within two to three hours for the first time.

To deploy, one or two people will be enough because you need Logstash to be configured to bring the data to Elastic Search for indexing.

We tried to implement big data pipelines and all, and we tried to use Spark as well for analytics and data cleaning, but I think Elastic is better in that field. I didn't find anything better than that.

My use case has evolved over time with Elastic Search. Initially, we started with it as a searching solution. Before Elastic Search, our primary source of truth was SQL databases, the traditional RDBMS. We thought about taking the data from the traditional RDBMS because they were not able to cater to the scale that we wanted to achieve, so we migrated the data from MySQL, keeping it as the primary source of truth, but for the searching mechanism and wildcard searches, we migrated to Elastic Search.

My experience with the relevancy of search results in Elastic Search includes both traditional keywords and full-text search. In the supply chain industry, with millions of orders and customers such as CMA CGM, Maersk, or Kuehne+Nagel, filtering out those orders was essential, using a shipment number, transportation order number, or an origin or destination number. In the gaming industry at FDJ United, full-text searches make more sense to understand gaming intent. For example, when a user searches for 'I really want to play action games', we break down that full-text query, use custom text analyzers, and derive the intent behind the user's query in combination with a vector database alongside Elastic Search.

My assessment of the effectiveness of hybrid search, combining vector and text searches, shows that Elastic Search is remarkable for text-based searches. I have explored other solutions, but none can beat Elastic Search in that area. When I combine hybrid searches with vector databases, they store the mathematical representation of the data. For instance, to find the top 10 closest proximity based on a query, the vector database uses cosine similarity on the available data and suggests the top 10 results while Elastic Search can keep the metadata, enabling quick access to the entire database based on derived intent.

I have utilized trusted GenAI experiences related to semantic search and text-based search in my current project using Elastic Search. My go-to solution for text-based searches will always be Elastic Search, but for semantic search, I am trying to build a solution that emphasizes system-level understanding agents. For example, if a new engineer queries the agent for a system explanation, it scans all the relevant data and provides a comprehensive analysis of the service, contextualizing inputs to reduce hallucination, controlled temperatures for the LLM model, and reducing nucleus sampling. As for knowledge preservation, I use a vector database to store significant outputs generated by the LLM, depending on user preferences regarding the gravity of the analyses performed.

The best features of Elastic Search that I appreciate include its capability for eventual consistent systems where you do not need hard consistency, and it scales very smoothly. For wildcard searches and regex patterns, it really scales massively. It offers ILM, indexation lifecycle management, which allows you to enable a search for a span of six months for the data fed into the system while moving the rest to a new cluster. The structure of the inverted index document facilitates its core features, and I find how Elastic Search understands, indexes, and creates mappings for your data to be remarkable.

While Elastic Search is a good product, I see areas for improvement, particularly regarding the misconception that any amount of data can simply be dumped into Elastic Search. When creating an index, careful consideration of data massaging is essential. Elastic Search stores mappings for various data types, which must remain below a certain threshold to maintain functionality. Users need to throttle the number of fields for searching to avoid overloading the system and ensure that the design of the document is efficient for the Elastic Search index. Additionally, I suggest utilizing ILM periodically throughout the year to manage data shuffling between clusters, preventing hotspots in the distribution of requests across nodes.

I have been using Elastic Search for more than six years.

In terms of stability, I would rate it eight out of ten regarding downtime, bugs, and glitches.

For scalability, I assign it a ten out of ten.

I would rate Elastic Search's technical support as nine out of ten.

Before Elastic Search, our primary source of truth was SQL databases, the traditional RDBMS.

Estimating the return on investment from Elastic Search is nuanced; however, I can share that initially, search times from traditional RDBMS were around two to three seconds, and with Elastic Search, we reduced that to 50 milliseconds, indicating a significant improvement.

Assessing the complexity of deploying Elastic Search, I have a gray area because a separate DevOps team handles that aspect, but from my experience writing code and utilizing its features, I find it not complex at all.

Estimating the return on investment from Elastic Search is nuanced; however, I can share that initially, search times from traditional RDBMS were around two to three seconds, and with Elastic Search, we reduced that to 50 milliseconds, indicating a significant improvement.

On the subject of pricing, Elastic Search is very cost-efficient. You can host it on-premises, which would incur zero cost, or take it as a SaaS-based service, where the expenses remain minimal.

When comparing Elastic Search to other vendors and products, I have recently explored Algolia, which is also a fully managed service. Elastic Search offers a choice between hosting on-premises or as a fully managed service, which has been beneficial compared to other solutions.

In my company's relationship with the vendor, I have always worked in product-based companies using Elastic Search, often as part of solutions from companies such as Manhattan Associates and in the gaming sector. For B2B industries, they sold to large clients such as Maersk and CMA CGM while my current company, Agoda, operates in the B2C space.

Elastic Search does require some maintenance, especially when considering features such as ILM if you want to enjoy its capabilities. Maintenance tasks depend on the established data pipeline and may introduce some friction.

Currently, we are not using Elastic streams for log ingestion; previously, we utilized the ELK and EFK stacks with Logstash for log ingestion and Kibana for visualization. I also observe a trend where companies migrate to Grafana Loki instead of ELK.

Regarding integration aspects, Elastic Search has exposed REST APIs for all its services, making it easy to integrate with third-party models or endpoints regardless of the underlying infrastructure, as any modern development language can interact with these REST services.

I have not used the attack discovery feature.

My deployment of Elastic Search is on-premises.

At Agoda, we handle over 1.2 billion searches daily, facilitated by Elastic Search.

While I have been at my current company for four months, I am still getting to know my colleagues; however, I know there is a dedicated team focused on Elastic Search. This team exposes a service that acts as an intermediary for communication between Elastic Search and other services.

In my department, there are more than 100 people, whereas the overall organization consists of thousands, exceeding 10,000.

I would rate this review overall as a nine out of ten.

I use Elastic Search for fast search of products in our database. With Elastic Search, we use full-text search with keywords and different rules from the Elastic Search documentation. I do not have cases when a search request is four sentences long. I typically use three, four, or five words for searches.

I think the best feature of Elastic Search is the speed. It is very fast and comfortable to use in requests with transpositions rather than full requests. It has a smart engine inside.

In Elastic Search, the improvements I would like to see require many resources.

I have used Elastic Search for two or three years, though I do not remember exactly which it is.

Maintenance of Elastic Search is easy because we do not have problems. I would rate the stability of Elastic Search at an eight.

I would rate the scalability of Elastic Search at an eight.

I did not have a situation where I needed to ask something in technical support for Elastic Search.

I used a different solution before using Elastic Search. It was Sphinx.

I do not know if the deployment was easy or complex, and it is also not my responsibility.

I do not know how it was purchased as it is our DevOps responsibility. I know that it is in AWS, but I do not know the details of how it is deployed there.

I do not know about features such as Agentic AI, RAG, or Semantic Search in Elastic Search. I did not know that there are AI search features available.

I would recommend Elastic Search to other people who want to have fast search in their applications. It is comfortable, it is fast, and it is very interesting to work with it. I gave this product a rating of eight out of ten.

I work in a gaming company where we handle a lot of microservices, observability, monitoring, and metrics. We aggregate all our logs to Elastic Search for troubleshooting across different environments including production, staging, and dev. We use Elastic Search to give us insights and to conduct a lot of troubleshooting.

We decided to go with Elastic Search because of the ability to aggregate everything into one portal where we have access to our entire infrastructure and the correlation about observability and traces. I have used competitors, but we are not using them in the production environment; perhaps on lower environments, but for production, we use Elastic Search.

One thing I appreciate about Elastic Search is the ability to aggregate everything into one dashboard, so I can have monitoring, logs, and traces in one portal instead of having multiple different tools to do the same.

Normally, if you were to use Prometheus, you need to know the Prometheus query language, but with Elastic Search, it gives us the ability to use normal human language for queries. It is very intelligent when it comes to querying. Unless you want to search something in depth, I find it very user-friendly.

I think hybrid search, which combines vector and text searches, is very effective because a developer or platform engineer does not need to spend time learning how to do a query. They can log in and use the standard query language to query a specific log, for example.

The initial deployment of Elastic Search was very easy for our instance because we just needed to enable some annotations for it to start getting the logs. We only needed to do a very minimal deployment on our side. The advantage we had is we had already deployed templates, so we did not need to configure each and every microservice. Once Elastic Search was there and we were able to push the annotations to our deployment, everything came alive.

I think the biggest issue we had with Elastic Search was regarding integrations with our multi-factor authentication tool. We had a challenge with the types of protocols that it allows. Sometimes you find it only supports one or two, and maybe we have a third-party tool for our MFA, so we are limited in how we can do integrations and in terms of audit. Since we are in an environment where we need to be compliant and have all our audits done, it is very hard to audit access logs for Elastic Search. I do not know if that has changed; perhaps we are still on an older version, but that has been the major issue we have experienced.

When it comes to updates for Elastic Search, we might need to push updates, for example, when they have a security patch that we need to enhance or add into our deployments. We do this in the lower environments for staging and then promote it into production. There is not much ongoing maintenance that requires any sort of downtime.

Elastic Search gives you quotas, so you are able to monitor your quotas and know when you are about to fill them up and maybe expand or tighten on your logs. Internally, we try not to have alert fatigue, so we only do important logs and queries, and we rarely have any sort of lag.

Elastic Search is very flexible when it comes to scalability. Being on the enterprise license, it is not really a big issue for us because we can increase the number of quotas we need depending on the logs we want.

For Elastic Search, we have never contacted any support. I appreciate the way they do their documentation and blogs. As a technical professional, before I reach out to support, I have to do my own troubleshooting and research; unless it is something that I cannot resolve, that is when I will probably raise a ticket. In the recent past, we have not raised any specific ticket for Elastic Search.

Before we migrated to Elastic Search, we were using the open-source tools Grafana and Prometheus for logs, but we had to have another third-party tool to do tracing such as Jaeger, or have Sentry to do database logs.

The initial deployment of Elastic Search was very easy for our instance because we just needed to enable some annotations for it to start getting the logs. We only needed to do a very minimal deployment on our side. The advantage we had is we had already deployed templates, so we did not need to configure each and every microservice. Once Elastic Search was there and we were able to push the annotations to our deployment, everything came alive.

The deployment of Elastic Search was done by our DevOps team, because I am part of the DevOps team. Our technical lead was mostly involved in terms of authentications and API key setup. From my side, it was easy for me to enable the annotations on the deployment and commit into the repository and push the changes to it. It was a team effort at different levels.

I would give Elastic Search probably an eight because there is always room for improvement. In IT, everything keeps evolving, and AI is here, and probably tomorrow something else will come, so they will need to elevate their game. I give it a general rating of eight, which for me means it is working perfectly, but it can always get better; there is always something to improve. My overall review rating for Elastic Search is eight out of ten.

Our use case is mainly for monitoring purposes, as we are getting the logs from our Linux machines where the applications are installed. Then we are forwarding these logs from the Linux servers to Elastic Search.

For now, we are logging the logs into the dashboard, and whenever a user wants to search on the logs, we use the platform directly on Elastic Search. I don't think we use full keywords; we directly use the user interface in the Elastic Search dashboard. Mainly, I think that should be sufficient for our users.

We don't use elastic streams for log ingestion or for structuring raw logs without agents.

We use the attack discovery feature to create alerts.

The best feature of Elastic Search that I appreciate is its monitoring capability. Whatever logs you want to forward to Elastic Search are pretty clear, and you can even edit the logs if you want some logs to delete or some logs not to appear in the monitoring dashboard, so you can clear it from there. It's pretty easy to install, easy to get handy on Elastic Search, and also easy to use it in the project. I think that's the main advantage of Elastic Search.

From a security point of view, I find Elastic Search to be quite secure, as we have a separate cluster that is well secured, and not just anyone can enter it easily.

I've noticed that the logs we are getting from the Linux servers have become automated, and in the long term, I believe Elastic Search will give promising results. When compared to Prometheus and Grafana, Elastic Search plays a main role in injecting SQL-related logs as it can inject any type of logs. It can show us any type of logs, which will be very helpful for any company or organization.

We forward the logs to our internal system that has an internal alerting system maintained by ING. The person monitoring Elastic Search, for instance, an ops guy this week or next week, will take care of the alert and try to fix it, making it quite handy to use this feature.

I think the first area for improvement is pricing, as the cluster cost for Elastic Search is too high for me. When I compare it with Prometheus or Grafana, we get very cheap dashboards with them. Elastic clusters are very costly; I understand the capabilities it has, but the price should be reduced a little bit in the market.

I also think the indexing throughput should be reduced, as using the bulk API in Elastic Search takes a lot of time and should become very fast. Additionally, observability features like search latency, indexing rate, and maybe rejected requests should be added to make the platform more reliable and accessible for everyone.

I have been using Elastic Search for close to two years in my current project.

As far as I have been using it for two years, I did not find any glitches or bugs, so I would rate it an eight or nine.

When it comes to scalability, it is scalable, but the pricing also matters, so I would rate it six or seven.

I would rate their technical support a nine because they are pretty reachable every time.

The deployment was easy for us.

We wrote some Ansible scripts, and it took maybe two weeks, a couple of weeks.

I don't think the hybrid search that combines vectors and text searches will be in my use case.

Currently, we are not using any of the trusted GenAI experience features such as Agentic AI, RAG, or semantic search.

I recommend Elastic Search to other people because it's quite reliable when used in a project. Every project can incorporate Elastic Search because it has a lot of features. The only concern I have is pricing; other than that, the features are very good. Everyone will be able to use it easily, but you need to keep in mind that you have to train some resources because there are not many people experienced with Elastic Search. You should provide some training to them before deploying them onto the project. I would rate this review an eight overall.

We utilize Elastic Search to bring a bunch of data sources together into a large search corpus, which is used to power our core research platform.

We don't generally do a lot of full-text search with Elastic Search. We do a lot of keyword-based searching and a lot of faceted search, and it works really well. We've also had to build custom relevance algorithms based on data that's being stored in the search index. This is more about the algorithm being less about text matching and more about feature matching and relevance on a number of different scales. It's generally worked out really well.

The best feature of Elastic Search is it does exactly what it says. It's really easy to get set up and running and have search running very quickly with basic, out-of-the-box features. It scales very well, and we can do a whole lot with the core feature set before having to move to more advanced concepts. Even then, it performs very well, whether we need to expand into vector databases or decide that the Elastic Search Query DSL doesn't solve our needs anymore and have to go with ESQL or something. It expands and scales really well.

The hosted solution means Elastic Search takes care of the maintenance, which is one of the reasons we chose it. There's been very little maintenance from a data perspective on our side. As we make changes to our database structure, we've had to mirror them into Elastic Search.

We haven't had the opportunity to use the hybrid search with Elastic Search yet. I think there's a place for it in our long-term solution, but we're not quite there yet.

We haven't yet used any AI features built into Elastic Search.

To do what we want to do with Elastic Search, the queries can get complex and require a fuller understanding of the DSL. Once we start to build that understanding, it's another muscle we have, so it's not a bad thing, but it just takes a while to get up and running with expertise for our engineers.

It's not hard to learn how to use more complex things in Elastic Search; it's just a challenge we're going to face.

In my career, I've been using Elastic Search for three or four companies, probably on and off for 10 years.

We've had various very small blips with Elastic Search, but it's never been an issue that was concerning. We have limited infrastructure, so we could go further in terms of our hosted deployment to ensure that some of those things didn't happen. We've simply accepted the level of risk we have.

Thus far, everything seems really good in terms of scalability for Elastic Search. We don't have the largest data set in the world; we have millions of records, single-digit millions, so two or three million records. I feel confident knowing that we could times that by 10 or 100, maybe, and it would still work. The cost would obviously scale, the number of nodes would scale, but Elastic Search would be able to handle that level of scale.

Before I was using Elastic Search and actually before Elastic Search even existed, I previously used Apache Solr and Lucene in my career. The release of Elastic Search way back when was a boon because it was out of the box and did what it said. We've also worked with Pinecone, Amazon's OpenSearch, and essentially Postgres trying to do vector search in Postgres. All of those tools have their place, but if we're doing straight search, Elastic Search is just really the right answer.

The initial deployment of Elastic Search was really straightforward because we used the hosted solution.

We had Elastic Search live and our first initial searches running in our staging environment within a week. We moved into production with our full data set within six weeks.

We had one engineer working on this implementation. That's why it took six weeks.

Elastic Search's pricing is affordable when using the hosted solution through Elastic Search. The pay-as-you-go monthly approach has been nice, and if we scale as a company grows, we'll probably switch to a prepaid model, which will be an even bigger benefit. Having the hosted solution and not having to pay for essentially a DevOps person on staff to manage makes it affordable. We haven't really looked into serverless, which has its own benefits. I think serverless still had some challenges early on, and I wanted to go with something I had previously worked with. The hosted solution pricing fits, but the pricing for serverless also looks really interesting. The self-managed solution is nice from a pricing perspective, but we need the right staff to support it, and we don't have that staff.

We don't use Elastic Search for log ingestion, though I think they have a feature for this.

We haven't worked with anything in terms of Elastic Search integration process for third-party models with interference endpoints.

I'm not using the Attack Discovery feature because we're not using Elastic Search for our observability approach.

We have no partnerships or anything with Elastic Search. I would rate this review as a 9.

Elastic Search is normally used for full-text search where users are fully depending on it for searching by name, address, and similar fields, and we need to gather the data with good latency, so we normally prefer to save it into Elastic Search.

Elastic Search helps for full-text search because we normally use it for keywords and other related terms. If there are keywords and searching requires numerical data and other elements, we prefer RDS over Elastic Search. However, if it is regarding complete full-text search in which we cannot do any kind of indexing and it is very difficult, we prefer Elastic Search.

Elastic Search's best feature is that it is very convenient to save, plus it is schema-less, and it has very good latency and also provides us with different kinds of mapping strategies which allow us to optimize many things according to the data structure. It is a kind of non-structured and structured mix.

The benefits of using Elastic Search are mostly for two to three purposes. For logging, it is very easy to insert the logs into Elastic Search and start searching it using Kibana, and it is very easy to make visualizations over there. The second purpose is that we normally use it for views. If we have searches from the front end with a specific structure, it is very difficult to go to a different table and create the query in the database, so what we do is sync our database with Elastic Search and create a view on Elastic Search which will give us the result in milliseconds. This is how we are currently utilizing it.

Elastic Search has an annoying limitation regarding page size. It has a specific limit for queries on Elastic Search, and the default is ten thousand, and we can increase it. However, after increasing, it can slow down. Pagination in Elastic Search is very slow. If I need to parse one million records saved into Elastic Search, it becomes a nightmare because I need to do the pagination, and it is very problematic in that regard. I need to do ten thousand records and then go to the other page, and when going to the other page, it currently takes much more time than RDS. For specific cases, if we need to do full-text search and searching for one specific word returns less than ten thousand records, it works very well. However, if we go for more than ten thousand, then it creates an issue for us.

It has been almost ten years since using Elastic Search.

Elastic Search receives a stability rating of nine point five; we rely on it.

In terms of scalability, for the managed service, it is very easy, but the scalability aspect is a bit tricky. Scaling up Elastic Search cluster requires a bit of time because of sharding and replications. It takes more time since it needs to copy the data. For example, if we are working on three nodes and adding a fourth node, the synchronization process will occur in the middle, and the higher the data volume, the more time it will take. Scalability is rated around five to six.

Elastic Search's technical support receives a rating of eight.

Previously, we were using the AWS managed cluster on the cloud, but now we have created our own. On the same cloud, we have deployed Elastic Search on our EC2 machines, so it is self-managed, not on-premises. On-premises would be if we give the solution to somebody else, then we would deploy Elastic Search on their specific cloud, but we only deployed it in our system.

I did not go into the deployment part of Elastic Search because it is a DevOps matter. I was in a senior role, so I sent the request and we received it. Normally, it does not take a lot of time if the person deploying is capable; it does not take more than two to three days.

We have about twelve specialists.

I cannot say much about the return on investment part because we normally work on a use case basis. If we find some kind of issue in our database which is currently taking time, then we need to shift to Elastic Search, and it will start giving us very good results. On the cost-saving side, rather than increasing our RDS from a less cluster to a big cluster, we can create a specific separate Elastic Search cluster, and it saves our money on our basic structure while giving us much more performance. I cannot tell you the exact part on how much was saved with the calculation, and I cannot provide the numbers, but it saves our time on the debugging side. Using it on the logs and creating visualization is very convenient for us to search the log and identify the issue as soon as possible. This saves our time, saves the customer's time, and decreases the time to respond and resolve.

Elastic Search's pricing totally depends on the server. Managed services from AWS are used, and we have worked on a self-managed Elastic Search cluster. On the AWS side, it is very expensive because they charge based on query basis or how much data is transferred in and out, making it very expensive. That is why we moved to the self-managed option. In self-managed, it is very easy to handle. We do not think any kind of proprietary Elastic Search solution is required.

Elastic Cloud Serverless is not being used. The GenAI experience with features like agentic AI, RAG, or semantic search is not currently being used. Kafka Streams is being used for log instigation.

Elastic Search has many pros, but the cons of it are that it is not structured, and we need to put all the things which are connected into a single index. Therefore, we cannot use it for our base structure database, but we always use it for supporting purposes.

While part of Careem, there were hundreds of thousands of customers using the solution, and now that in a startup, the clients are no more than one hundred.

Elastic Search requires maintenance. We need to keep it updated because Elastic Search normally launches new features and versions on both Kibana and Elastic Search sides. We need to keep updated ourselves, and also, we need to do maintenance on the storage side. Normally, we use Elastic Search for timelines, saving all the data from beginning to end, so normally the storage maintenance is an issue, and we have to increase the storage time to time, but it is not related to Elastic Search; it is actually related to our use case.

There is lots of support for Elastic Search in different tools like Logstash which we normally use for integration, and there are other tools as well, but it is very easy and not a big issue for that.

The Attack Discovery feature is not being used. Big businesses cannot survive without Elastic Search because it gives us very good visibility and handles our use cases very well. If we need something reliable and trustworthy as a solution, then Elastic Search is the way to go, as it is an integral part of big solutions. The overall review rating for Elastic Search is eight point five.

Elastic Search is being used for two main streams. The first use case is an internal analytics engine for the usage of our services, which is based on logs that are put into Elastic Search indices to build different dashboards for key executives and developers, providing different levels of information. This is essential to provide statistics as a nonprofit organization funded by the Department of Energy and other infrastructures. The main focus is on web access to the Protein Data Bank for scientists and bioinformaticians with a publicly facing service supporting roughly 15 million users and an average load of about 700 requests per second. There are two data centers, one on the East Coast and another on the West Coast, serving the same publicly available interface. Logs from these services are monitored and collected, then put into Elastic Search database, from which different perspectives are provided for various stakeholders.

The second use case is Application Performance Monitoring, where Elastic Search APM stack is used to collect application performance metrics, primarily using Java, with a bit of Python and Node.js. Those three agents are used along with a standard infrastructure with the APM server that injects everything into Elastic Search indices for incident recovery and finding performance bottlenecks. As a nonprofit organization using an open-source license, there have been no problems with Elastic Search trying to change the license. Since no commercialized services are provided, the organization remains out of the scope of those issues and continues using open-source licenses. Recently, integration with an internal Keycloak instance was completed to provide role-based access to the Kibana application, which was a bit non-trivial but was managed successfully.

The experience regarding the relevancy of search results with Elastic Search is positive since it is used for providing search features for end-users of the Protein Data Bank. During ETL processes, information is collected from different data sources regarding proteins, including protein annotations and structures, which are transformed and loaded into the internal database. One part of that database includes Elastic Search indices. For search capabilities, full-text search is performed for end-users while keyword search is used primarily for internal needs, and no complaints have been heard about either of them.

The main focus is on web access to the Protein Data Bank for scientists and bioinformaticians with a publicly facing service supporting roughly 15 million users and an average load of about 700 requests per second. There are two data centers, one on the East Coast and another on the West Coast, serving the same publicly available interface. Logs from these services are monitored and collected, then put into Elastic Search database, from which different perspectives are provided for various stakeholders.

There are a couple of improvements that would definitely save a lot of headache with Elastic Search. One would be if the open-source license had multi-user access to Kibana, which exists in the paid tier license. There were also some difficult times with parallel and point-in-time interfaces, so better documentation could help, particularly more example-driven content. The provided documentation tends to have some common words but lacks real applicable examples. More specific examples, such as step-by-step guides, would be ideal. From a technical point of view, there are no significant issues recalled as Elastic Search has been absolutely awesome for this use case and covers 100% of the needs.

Elastic Search has been used for roughly five years.

Regarding stability, there are no major incidents recalled with Elastic Search. While not part of the DevOps team, nothing significant has ever exploded to affect the whole organization. If there were issues, the DevOps team was able to fix them quickly. Problems have been experienced with other services, but not with Elastic Search.

In terms of scalability, Elastic Search is good for this organization. A standard three-node setup with multiple clusters is being used for internal and public needs, resulting in six nodes per database across the data centers.

There has been no need to contact customer tech support for Elastic Search. It has been sufficient to visit conferences such as SCALE in Southern California Linux Expo, where Elastic Search has a booth to talk to their staff. The organization often relies on publicly available resources such as forums, issue trackers, and an internal knowledge base. Once, a ticket was created on GitHub concerning a Kibana issue with Application Performance Monitoring, but that was essentially the extent of it. The main sources of support are conferences and documentation.

No alternatives similar to Elastic Search have been tried. When the discussion about the open-source license started, OpenSearch was briefly looked into but the decision was made not to move forward because the organization felt secure in the current usage without commercialization.

Elastic Search AI, RAG, and semantic search have not been explored yet, as those opportunities for integration are just beginning. Nothing has been moved into production, so further comment cannot be provided. Standard agents from APM are being used to collect telemetry metrics and send them to the Application Performance Monitoring server, which are different from AI agents.

It is difficult to assess the current pricing of Elastic Search because the organization is in a specific niche as a nonprofit organization. On-premises instances are managed internally and a managed option had been considered, but that did not pass the board's approval. Open-source licensing has worked well, and there have been no ceilings where payment options for additional services needed to be considered. Users are quite satisfied with what is provided, and the organization is happy with what is received from Elastic Search.

The learning curve with Elastic Search was very easy. With a strong background in Java and software engineering, and having a great tutor in the organization who showed how to perform ingestion pipelines with Grok and how to use the development environment within the stack, the process was manageable. While it might be difficult for middle-level and junior developers, having someone experienced in the organization makes it manageable to share knowledge.

Elastic Search mostly requires maintenance during upgrades. While it is running in standard mode, there have been no major incidents from memory, so it has quite low maintenance requirements.

There are no official partnerships with Elastic Search; the organization is just a user utilizing the open-source license. Overall, this review has been given a rating of 9.

Elastic Search is used as an observability tool and logging analyzer for solutions that already exist in the company, mainly in FinTech products and financial products.

Elastic Search's main advantages are the visuals that represent and visualize all entities and system components in a simplified diagram, which provides the ability to identify which component in the system has an issue.

The main benefits include having one centralized place that gathers and aggregates all logs related to different or distributed systems.

Elastic Search could be enhanced by incorporating low-code or no-code plugins that permit developers to integrate it with different or distributed systems. This would allow for configurations that already exist but need customization through plugins or simple code that can facilitate user control over parts of the visuals, dashboards, and sensors.

Graphs should be more interactive by importing different graph schemes or visuals from external resources into Elastic Search.

Given that the product has not been used since 2023, the data might be outdated. If Elastic Search is not integrated with any promised LLM, it should have this capability as soon as possible.

Elastic Search has been used since 2018 to the present moment, depending on the different companies that have been worked with.

Elastic Search is a very stable product, especially after obtaining support licenses from Elastic.

The scalability aspect is straightforward. With self-hosting, resources can be expanded vertically, which is managed from the organization's side.

There is no knowledge about general customer service, but there is previous experience in submitting support cases to the Elastic team to get answers and fulfill requirements.

Elastic Search was installed one time but the work was not completed with it.

Experience exists with Dynatrace observability tool, but Dynatrace is completely different from Elastic Search. Dynatrace is comparable to other observability tools in this category.

Elastic Search has been installed in multiple organizations, including the current employer and previous ones, and used for different purposes.

The setup is somewhat complicated due to multiple dependencies and relations with different systems. However, any engineer should be able to understand and read the documentation well to implement it properly based on business needs and requirements.

The implementation team was involved in the deployment.

Return on investment was achieved more than a year ago.

DataDog might be an equivalent product to Elastic Search, though this requires verification.

Hybrid observability was not used. Enterprise API, whether referring to ESB, API Gateway, or middleware, was not used. Serverless interaction with Kibana was not used. The overall rating for this review is 9 out of 10.