Elastic Search Reviews

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.

Positive

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

Positive

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.

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.

I use Elastic Search, and from time to time I use it, but most of the time I am a system administrator. I deployed it more than using it. At the beginning, I was a system administrator, responsible for the deployment and maintenance of Elastic Search clusters. For a few years now, I have started to use it more because the end users are rookie users. They need a lot of help to be able to use Elastic Search effectively. I started to be a user approximately five years ago.

Today, at least, we provide a global, unique Elastic Search cluster for the whole company, and all teams store their logs inside, their traces, and their APM traces. Teams use Kibana to display information. We also use Prometheus exporters to collect metrics from the logs. We execute some query DSL over Elastic Search to collect metrics, which will be injected in a time series database like Prometheus. This is the main usage. We store metrics, logs, and APM traces.

The deployment of Elastic Search is excellent. I like Elastic Search very much for that. I say regularly to the team that Elastic is elastic. It is really difficult to break. This was not the case a few years ago when I worked with Elastic Search version one and version two. Starting with version six of Elastic Search, it started to be really strong. Today, in the past, the main issue was about the data and the volume.

At the moment they integrated lifecycle policy for indices, ILM, Index Life Cycle Management. When it was created, additionally to the data stream, it started to be really easy to have all the same index volume. It is really easy to administrate and to balance data between data centers and between data nodes, and to keep the same everywhere. It is very nice. It is my favorite feature of Elastic Search. It is so easy to manage. Also, maybe because we used it for a long time, we started to be comfortable with all the setup and the node type, and how we should manage our cluster to make it resilient. I think it is really easy to maintain comparatively to some other databases.

To be honest, there is only one downside of Elastic Search that makes sense because we use a basic license, which is a free license. We do not have some features available because of the free license. Except for that, I do not have any complaint. It works perfectly. It is pretty easy to administrate and to use. I do not have complaints, to be honest, except the fact that we do not have all features available such as the APM service map or alerting.

We are not able to use a provider like Sentry, Slack, or PagerDuty. We are forced at some point to generate metrics from the logs in order to use our alerting stack in Prometheus, which works. It is an open-source project which allows us to generate alerts to Slack, PagerDuty, and some third-party tools without any license. However, it is not doable with Elastic Search in the open-source version. The alerting part is the most complicated part to manage because of the license.

From time to time we have some JVM, Java Virtual Machine issues with Elastic Search. However, it is more linked to users' requests. From time to time, people ask Elastic Search to search inside one year of logs without a nice query and without any filters. This is clearly not doable and some nodes will crash. This makes sense. However, Elastic Search is really stable when we do not have this kind of request.

Elastic Search is the perfect tool for scalability. You just need to deploy new nodes. They will be able to join and reach the cluster really easily. I appreciate it for that as well because today at VP, we use Terraform to deploy our infrastructure. All Elastic Search nodes are managed through Terraform. If I need to extend my data node or my ingest node or whatever, I just need to deploy new nodes with the same setup, and the node will join my cluster, and it will scale horizontally really easily.

For logs management, I have not used any alternatives or something similar to Elastic Search. For APM as well, there was a plan in the past to try to migrate to Grafana, the Grafana open-source platform for APM traces using Tempo. Tempo is a Grafana Labs project. However, we decided to keep Elastic Search for that, so we do not have any other tool or similar tool to accomplish that.

Maybe just one, it is about error tracking. We can track errors with APM inside an application, and currently we use Sentry, which is not just an error tracking platform, but also about performance management. However, we use it only for error tracking. It is more useful for developers at the beginning of a new project. Most of the time, they prefer to be connected to Sentry more than APM in order to track errors. When the project will be in production, they will be more focused on the performance than the errors. At this moment they will start to use APM, Elastic Search APM more than Sentry. We do not provide any performance indicators. Sentry is also able to manage performance metrics, but we use it only for errors and everything related to performance has been disabled.

I think the pricing of Elastic Search is really, really expensive. The main point is that we do not get any license. I tried in the past, a few times, to contact the Elastic Search team to get a quote, and it was so complicated each time to get a quote because of the volume and the number of nodes. We are a big company at VP, so we have a lot of nodes, more than one hundred. For sure it was so expensive. They tried to tell me about the enterprise mode and about the new license way to manage cost based on CPU and memory usage. It was really expensive because at this moment, we do not use any cloud services. Our Elastic Search cluster is on-premises.

Everything is self-hosted at VP tech, at VP. We do not have any limit. People using AWS or GCP have limits because the volume of data is really expensive in cloud services and cloud platforms. Because we self-hosted everything around our services such as Elastic Search or Sentry, the idea is to let the user be able to store a lot of data and a lot of metrics. We try to train the team to have a good log level. We do not have such limitation in terms of volume. We have a really big cluster, and at the end, the price is so huge. I gave this review a rating of ten out of ten.

The major purpose was to solve the search part. We have data in multiple languages, majorly in Indian languages such as English, Hindi, Punjabi, and some Marathi and Bengali. There is a requirement where we need to support a kind of listing, and I can say there is a list of people or users to whom I want to search.

What I like the most about Elastic Search is that I can store my data and search throughout my document. It is not like I am doing a search on a particular field only. For example, in comparison with other databases like SQL or NoSQL, you can implement search, but you need to be restricted to a particular field. In Elastic Search, there is an opportunity to search the entire document, and if there are any matches, it gives a score based on which I can decide how much data I need to show.

For example, if I am searching a person's name, there is a chance that the person's name I will be looking for may have some partial match. If I search for Amit, there can be multiple spellings for the same thing. It works on a kind of phonics system, which is a major requirement for me because when people type, they usually make spelling mistakes.

Regarding what I dislike about Elastic Search, there is one issue that occurs because Elastic Search is not my primary database; it serves as a substitute database for the searching part. I need to sync my data, and if I am not using the enterprise edition or version, sometimes my entire servers get crashed or backups crash. If I need to recreate that same thing again, it will take a lot of time, as the restore and sync process is very slow.

I have been using Elastic Search for the last three to four years.

Regarding stability, if I am deploying myself, I feel many issues during deployment due to maintenance that I have to take care of. Sometimes the CPU or memory spikes depending on the load. However, I have noticed that an enterprise solution seems to be carefully handled by Elastic Search itself.

I have almost handled ten to twenty million data entries, and we have gotten results from that. I think I have seen that level of scalability in Elastic Search.

I have contacted technical support or customer support several times, but not me personally; my DevOps team has connected with the technical support several times. They deal with the contact support because they handle all the infrastructure setup and issues related to DevOps.

I have used other similar solutions to Elastic Search. I think Elastic Search was compared to lexical search or something similar. There is another solution provided by MongoDB which also does similar work; with them, we can restore the JSON format data quickly compared to Elastic Search. MongoDB provides a tool called Compass, and they have Atlas. In Atlas, they are offering a lot of solutions with many features that were missing in Elastic Search. While the searching part in Elastic Search works fine, it lacks a lot of things; for instance, if I need to scale or downgrade my system, the backup restoration works much faster.

The initial deployment was something I was not part of for Elastic Search, and even for Mongo not much. However, I have some idea about it; you can create multiple shards and similar configurations. It is easy in both cases.

A lot of maintenance is required on my end. A lot of data needs to be synced because we were using CDC, so a lot of data is transmitted from my primary database to this secondary database for searching purposes. That requires a lot of effort. However, using the cloud solution, I think it can be set up; but again, it costs me a lot.

My experience with the relevancy of the search results when using traditional keyword and full-text search capabilities shows that as we are moving towards AI, you can keep all your data and break it into an AI format. Whatever I want to search, it will give me a result. I think moving forward, plain text search will not be a long-term solution because as people are moving towards AI, they want machines to understand better what they are trying to search. For example, I may want to search for a person based on department and years of experience, and for that, I think Elastic Search will suffice. However, breaking data into tokens and embedding it for querying will be a better solution moving forward. Elastic Search is also providing some sort of AI solution, but I have not had much time to explore that yet.

I believe the effectiveness of hybrid search, which combines vector and text searches, is great because vector search deducts information from the text provided to a machine and effectively gives the related data. If I use vector search with plain text in a hybrid search, it will be a better solution moving forward. This is because people do not want to search for something such as Atul Kumar; they want to search for Atul Kumar from a specific department or company, region, or city. My overall rating for this product is eight point five out of ten.

My main use cases for Elastic Search involve search capability. For instance, I built a banking product application, the PFM personal information system, requiring search capability and fuzzy search using Elastic Search. Additionally, I use third-party API data to build a super app in the insurance domain, where I collect requests and responses from APIs and store the logs in Elastic Search for debugging purposes, analyzing the data using the Kibana dashboard.

I previously used Space Cloud to build similar functionality; however, it does not support fuzzy search, which is why I switched to Elastic Search for those requirements.

One of Elastic Search's best features is its search capability due to the index-based data management and lifecycle of unstructured data, primarily in the form of JSON, allowing for historical data storage and multiple indexes.

When using traditional keyword and full-text search capabilities, my experience with Elastic Search's performance indicates that the results are obtained much quicker compared to traditional SQL queries, demonstrating superior efficiency.

Elastic Search fulfills my use case requirements effectively, both for my current and previous needs, which is why I rely on it.

Elastic Search positively impacts my company with many benefits across multiple use cases; for example, it enables quick dashboard setups for client reviews and presents data efficiently, ensuring good user experience.

I think Elastic Search could be improved by introducing more AI features, particularly for complex queries and aggregator functions to enhance usability and readability.

Over the last four years, I have been using Elastic Search, including both the open-source version and the open search provided by AWS.

Elastic Search is stable in my experience.

Regarding scalability, Elastic Search provides horizontal scalability options on AWS, allowing me to scale according to my requirements and traffic.

Technical support for Elastic Search is satisfactory, with quick solutions provided by support teams and active open forums available. I rate customer service and technical support as an eight out of ten.

Before choosing Elastic Search, I evaluated other products like Space Cloud and three to four different banking applications, ultimately finding Elastic Search to be the most capable option.

The initial setup process of Elastic Search is straightforward, with comprehensive documentation available for installation guidelines that make it easy for beginners.

Pricing for Elastic Search setups is dependent on requirements and use cases, but I find the enterprise license to be reasonable in comparison to other products.

I am currently using Elastic Cloud Serverless.

My application is hosted on AWS cloud, utilizing managed services including the open search, which is a component of Elastic Search.

I use the ELK stack for log ingestion and visualization of application logs via Kibana.

I find that the ability to parse and structure raw logs without agents requires different approaches for each use case.

I am using the Attack Discovery feature.

The discovery feature helps me correlate alerts by writing custom queries to retrieve logs based on specific criteria.

I utilize generative AI models like Claude AI and Anthropic within the discovery context for better log analysis.

From a technical point of view, integrating AI capabilities within Elastic Search enhances its value, showcasing the potential for using models and RAG in my systems.

I recommend Elastic Search for companies with substantial data needs or searching requirements, considering it the best search engine. I have provided an overall review rating of nine out of ten.

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.

Negative

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.

As a developer, I use Elastic Search in developing one of my applications, basically integrating the back-end with Elastic Search.

Our main use case for Elastic Search is for Logstash, which is a subset of Elastic Search that allows us to store logs and enables searching between logs with specific keywords in specific time ranges. Apart from that, we have our data stored in an index, and since Elastic Search is a NoSQL database, that's how we store the files in our databases.

The main objective of integrating Elastic Search is to transition from normal SQL databases to have faster searches and dynamic queries built around it, which makes the search much quicker. Since not all data is structured, we also need to handle unstructured data, and that's how Elastic Search has replaced our previous system.

The positive impact I've seen from using Elastic Search includes replacing conventional databases and being able to store much more unstructured data. In the future, if we need to include data not present in earlier systems, we can implement semantic or flyway changes with Elastic Search in place, allowing us to store unstructured data as is.

The most valuable feature of Elastic Search that I appreciate is the dynamic query building and the speed of result fetching, especially since we have an open-source version called OpenSearch that we use in specific places due to the cost of storing data with Elastic Search.

Dynamic query building and result fetching are valuable because there are specific use cases where we need to build queries based on environment variables rather than having a generic query. This dynamic building helps address various business scenarios, especially considering customer product types and flags that may need inclusion or exclusion in the query. It allows me to create one query to accommodate multiple business cases and ensures that user-specific scenarios are included, with results already fetched for each.

Elastic Search has many features, including Kibana and Logstash, which we regularly use. However, one downside in our product is cost, as it can be expensive when maintaining multiple shards and indexes. Failures of shards or nodes can occur, and I can mention that cost and the upscaling of nodes or shards are areas needing improvement.

We haven't explored the hybrid search feature of Elastic Search, which combines vector and text searches, yet.

Scalability of Elastic Search presents disadvantages, particularly when handling minimal or production-level data. It manages high volumes of unstructured data well, but during performance tests involving one million requests at once, we encountered issues with shards and nodes not upscaling as needed, leading to crashes and minimal data loss, which isn't typical in real-world scenarios.

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

Elastic Search is quite reliable for us, and despite identifying some very minute limitations, we still rely on Elastic Search.

Scalability of Elastic Search presents disadvantages, particularly when handling minimal or production-level data. It manages high volumes of unstructured data well, but during performance tests involving one million requests at once, we encountered issues with shards and nodes not upscaling as needed, leading to crashes and minimal data loss, which isn't typical in real-world scenarios.

I have not communicated with the technical support of Elastic Search at all up to this point.

Before Elastic Search, we used Couchbase, which is also a NoSQL database. Initially, it was free software integrated into our applications, but with its commercialization, we explored alternatives and found that Elastic Search would be a better fit than Couchbase.

We conducted some preliminary research to find a potential replacement for Couchbase while searching for NoSQL databases. The good documentation for Elastic Search on various websites helped us conclude that it would be an ideal fit. Although we considered the open-source version known as OpenSearch, we decided to integrate Elastic Search to explore its features, eventually determining it had much more powerful features, such as the Kibana dashboard and Logstash.

With respect to performance, we have seen a return on investment from Elastic Search. For example, the API response time has improved significantly, cutting the time down from about one or two minutes to around 50% faster, benefiting our downstream applications.

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.

Negative

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.

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.

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.

Positive

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.