I have completed two different Elastic Search implementations, and in both cases, the goal was to speed up very slow Postgres databases. As a platform PM, I am typically responsible for user management and company management. These areas are quite heavy depending on how many users, customers, or companies exist. Before Elastic Search, when we relied solely on Postgres, there were significant delays to user list pages and company list pages. In the other company, there was a lot of data displayed for particular list pages for admins. We combined Postgres with Elastic Search to speed this up, and it certainly does speed it up. We have used it throughout my current job and previous job.

From the customer side, Elastic Search is super fast and very efficient, delivering results quickly. We recently tuned a series of compliance results in the CMS where we would specify that certain results should come up higher by adding keywords and other factors. However, the results were not as good as when we restarted and used Elastic Search out-of-the-box search results. We actually got better results that were more logical.

The most significant issue I find with Elastic Search is that it gets out of sync, and this has happened in both cases where I have implemented it. When Elastic Search gets out of sync, for instance, if I create a company or user, it gets created in Postgres and then sometimes there is a delay for it to appear in Elastic Search. This could be a 15-minute delay depending on how it was implemented. If other significant processes are running on the platform where you are touching a lot of records, such as a million records, that will take a hit on Elastic Search. We have seen differences of 800 records between Postgres and Elastic Search. Proactive tools that would find and adjust any mismatches would be beneficial.

Occasionally, Elastic Search has failed, and when that happens, search results do not come up at all. This has been a rare occurrence, and I am not certain Elastic Search is entirely to blame, as it could have been platform storage or other factors. For the most part, the most common problem is the out-of-sync issue.

I have used Elastic Search since 2019 at the last two companies where I have worked.

I would say Elastic Search is pretty scalable. We have had good results.

Earlier, in the 2019 and 2020 range, we were having a lot of trouble with syncing, and we tried to see if consulting was available. At the time, we could not find what we needed from the knowledge bases, and we could not really get support. There was not a technical support option at that time. That may have changed. Currently, I do not think we have gone to Elastic Search to ask for any significant help.

Google Appliance was a search engine that Google had for a while, and we used that and were pretty happy with it, but then they deprecated it and it is no longer available. After that, I do not remember what we used, something else.

Although I am not an engineer, it seemed easy to medium to set up. It was not complicated.

For the initial rollout, I would say it was maybe two or three people for the initial implementation, and then I have a team of 40 or 50 engineers with somebody always working on updates and other tasks.

We have not yet used anything in combination with Elastic Search, but that is on the roadmap.

I would say Elastic Search's relevancy is okay, and if I were to give it a score, I would give it a B. Elastic Search works best out of the box as much as possible. When you start to overtune or put in other factors that will increase the priority of specific results you want to come up, it gets really complicated and then you do not necessarily get the best results.

Elastic Search works best when used out of the box without excessive tuning. My overall review rating for Elastic Search is seven 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.

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.

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.