Elastic Search Reviews

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.

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

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

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

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

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

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

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

Positive

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

On-premises

Other

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.

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.

I am a customer, and I use Elastic Search to enhance our search capabilities in our applications.

Elastic Search has excellent features, particularly its scalability and speed. What I appreciate most about Elastic Search is the ability to handle complex queries efficiently. I assess the relevancy of the search results by comparing it to hybrid search methods, such as vector and text searches, which helps ensure the accuracy of the results.

I see that there are areas in Elastic Search that have room for improvement, such as user documentation and onboarding processes.

Regarding the stability of Elastic Search, I find it to be quite robust, and I rate it a 9.

Regarding technical support, I would rate it an 8 because they are responsive and helpful.

The deployment took about two weeks, as we needed to ensure everything was configured correctly.

I compare Elastic Search with other solutions, such as OpenSearch or Algolia, in terms of features and performance, which are quite impressive.

Elastic Search requires regular maintenance, including updates and patching to keep it running smoothly, and upgrades are straightforward to implement.

I have used Elastic Stream for log investigation, which has been very helpful in diagnosing issues. We have about 50 active users in our organization.

Hybrid Cloud

Other

We use Elastic Search for a research application based on paper study, and the primary usage is for indexing the data and then functioning in a similar way to an e-commerce search bar.

For us, what I can notice is the ability of adding weights to each field of the data, which is very useful because sometimes the user searches the data not just by the title, but by specific keywords, and being able to add weight to the fields in order to show that information to the final user is very useful. Also, the panel for showing graphs about the data and how the users are interacting with it is pretty useful.

The difference in performance of Elastic Search is outstanding; if we compare a traditional database or service for search and index products or, in this case, papers, the difference is outstanding. That is the case when you want to filter the data; the primary advantage will be performance for sure.

Again, the primary improvement will be performance, and the interactivity we can have with the data is very flexible; it adapts to the needs of the user very easily.

I cannot see any issues at this point; the panel is great. The way to customize and configure the panel and the search is great; it is really visual. Documentation is great as well.

The initial configuration could be easier; at first, the learning curve is a little high, and over time, it becomes easier. For me, the initial configuration might be improved.

I have around three years of experience.

Stability has not been an issue; it is working perfectly in that aspect.

Scalability has not been an issue for now.

In the case scenario when we need to face support, support was really useful, and they answered the questions in a good period of time.

Cassandra was one we were evaluating, but we preferred Elastic Search because the documentation was way better and the community was bigger. It is easier to find answers when we face a problem, and that is why we chose Elastic Search.

At first, we faced several issues related to some versioning and allowing indexing the database because part of our information is in a traditional SQL database, and we were using the IDs from the index for the records in Elastic Search. We created a little ETL for that, and handling that process was tricky and harder at first. That was the biggest challenge we faced when starting to set up Elastic Search.

I would say that first, contact support for the initial setup; I think it will make the process easier. Then start, for example, with how to send and retrieve the data in the documentation; I think that is the best thing they can do.

For that one, my field, the PO and the technical leader is the one that handles the bills about Elastic Search.

I am on the side of implementing it, so in terms of cost-efficient or the price of using it in the cloud, that is not something I am really involved with; I am more on the dev-ops side.

It was great; the developer experience is great when integrating either the frontend or the backend side. Nothing so complex could not come.

For implementing Elastic Search, I would say good documentation, and it is really easy to use. We have an example of almost every functionality that is inside of Elastic Search framework, so that is helpful. I would provide a rating of ten for this product, and I say a ten; it is really good.

Public Cloud

Amazon Web Services (AWS)

We are using Elastic Search for free text search. We scan cache files and convert them into OCR. This allows our end users to search for any judgment given in the 1980s or 1990s based on their criteria. 

Elastic Search is very quick when handling a large volume of data. The facet search is particularly valuable. It is scalable. Elastic Search makes handling large data volumes efficient and supports complex search operations.

There should be more stability. When we started learning it, new versions came out frequently in one quarter with extended features. This can create problems for new developers because they have to quickly switch to another version. Stability could be improved, as it sometimes requires quick adaptation to new versions.

We have been using Elastic Search for two years.

Elastic Search is generally stable, however, the frequent release of new versions can cause challenges for stability. If asked to rate stability, I would give it an eight out of ten.

Elastic Search is scalable. Our supreme court uses it for the whole nation across all judgments, so it must be scalable.

We have not contacted customer service. We rely on documentation for solutions.

Positive

We are using Elastic Search for free text search in our project.

The documentation for Elastic Search is very well structured. It provides easy-to-follow steps for installation, making it a straightforward process.

One person can install Elastic Search by following the documentation steps.

Our organization prioritizes open-source tools. We have not purchased any licensed products, and our use of Elastic Search is purely open-source, contributing positively to our ROI. We adopt open-source tools due to the organization's policy.

Our experience has been positive, finding solutions in documentation without needing customer support. We also use supporting technologies like PostgreSQL, Spring Boot, and Subversion for seamless integration. 

I rate Elastic Search nine out of ten.

I have used the Wazuh SIEM tool, an open-source SIEM tool that uses Elasticsearch for indexing. In this SIEM tool, we have a large amount of logs. Data are converted into alerts, then they are stored in our environment for monitoring and security purposes. For storing that data in Wazuh, we use Elasticsearch indexing.

Configuring Elasticsearch is much easier compared to comprehending other SIEM tools like Splunk. It has a full command-based access that allows you to configure how much data you want to store and set up retention policies. I can easily change the bandwidth for the network to send log data. Elasticsearch is quite user-friendly and offers a hands-on experience for configuring databases.

Elasticsearch should have simpler commands for window filtering. It is primarily based on Unix or Linux-based operating systems and cannot be easily configured in Windows systems. Multi-operating system support would be a great improvement.

I have used it for approximately two years.

It can be installed on cloud and locally, with no issues.

I would rate the stability of Elasticsearch as a seven. There have been multiple instances where I faced errors due to network bandwidth issues. The data transfer sometimes exceeded the bandwidth limits without proper notification, which caused issues.

I would rate the scalability of Elasticsearch as an eight. The high scalability is somewhat limited by its lack of support for different operating systems other than Linux.

I have never used their technical support. I usually resolve issues on my own or with the help of online community forums.

Positive

The complexity of the initial setup depends on the requirements. In an MSSP scenario, where multiple clients use the same software, there is a need to segregate the data. This can make the setup more complex, especially for a single client where you need to adjust network configurations.

For time-saving, Elasticsearch is a good software. It is stable, and we do not encounter critical issues like server downtime, which could result in data loss. There are minor misconfigurations regarding data transfer rates that I have noticed sometimes.

I'm not familiar with the pricing details as it falls under the finance department. My manager handles the costing. However, given that we have been using it for two years, I can suggest that it's priced sensibly for us.

If you can't afford a large SIEM tool like Splunk and QRadar, Elasticsearch is a viable alternative.

Overall, considering key aspects like cost, learning curve, and data indexing architecture, Elasticsearch is a very good tool. I would rate it as a nine.

I use the solution to store historical data and logs to find anomalies within the logs. That is about it. I don't create dashboards from it.

I find the solution to be fast. Aggregation is faster than querying directly from a database, like Postgres or Vertica. It's much faster if I want to do aggregation. These features allow me to store logs and find anomalies effectively.

I found an issue with Elasticsearch in terms of aggregation. They are good, yet the rules written for this are not really good. 

There is a maximum of 10,000 entries, so the limitation means that if I wanted to analyze certain IP addresses more than 10,000 times, I wouldn't be able to dump or print that information. I need to use paging or something similar as a workaround. That's what the limitation is all about.

I have probably used it for three or four years, maybe longer.

The solution is very good with no issues or glitches.

In terms of scalability, I have multiple Search instances. I can actually add more storage and memory because I host it in the cloud. It's much easier in terms of scalability, and I have no complaints about it.

I have never talked to technical support.

Neutral

I am using Elasticsearch.

The initial setup is very easy.

I did not use any outside assistance.

I don't know about pricing. That is dealt with by the sales team and our account team. I was not involved with that.

I am evaluating InfluxDB as well. Timescub is a kind of database.

I would rate Elasticsearch at eight out of ten.

Public Cloud

Other

I am familiar with Elastic Search to a certain extent as I have used it in my development life. I thought someone wanted feedback about it, specifically how I have used it in my career, so I agreed to share that information.

I started using Elastic Search after becoming acquainted with it when I accessed the AWS environment for the first time during the COVID period. We tried to establish a vertex and edge graph database schema, and I was hired to get that schema up and running while dealing with millions of records related to car spare parts. Due to a signed clause, I cannot go into too much detail. The challenge was with the indexes slowing down, which prompted a move to GraphDB because it provides faster access time. I had to deal with a lot of data cleansing and created many pipelines, first pushing records into Elastic Search through a bulk insert. I also looked up data using Kibana as the front end to leverage queries for pulling up that data.

Once GraphDB was in place, I was required to develop a service for asynchronous processing and order confirmation, where one copy would be stored in a database and the other would be pushed into Elastic Search for further lookup, eliminating the need for direct queries to the RDS

I have never reached out to Elastic Search's technical support team.

Elastic Search, being a vector database, quickly indexes data, allowing for searches based on text and data directly, which I found fascinating. My dev lead mentioned that it uses C++ to pick up these indexes and pulls up records incredibly fast, in nanoseconds, keeping me interested in how things are becoming faster over time and diversifying away from traditional relational database systems.

Regarding scalability, I consider both vertical and horizontal scalability in theory. I have not experienced sharding but find it interesting as a use case with Elastic Search. I see significant potential for vertical scalability, which can accommodate more data and offer substantial improvement.

Your question about what I dislike about Elastic Search is quite pointed, and I prefer to look at it as something for improvement, such as provisioning options other than Kibana. A standalone install that is operating system agnostic could run on Mac, Linux, or Windows by just providing a URL, username, and password to access the schema for queries. This would benefit many people who may not have access to Kibana, especially those who, the workplace evolution has shown, may not know what Kibana is if they lack tool access. It is crucial to have executable information to understand a product deeply. If Kibana is not a viable option for everyone due to hosting constraints, a standalone installer could connect directly to Elastic Search, with documentation readily available online to guide those needing desktop access.

I have been using this solution for two years overall and have had good exposure to it with all CRUD operations I have been performing with it.

I have used Elastic Search for log lookups with ELK and never encountered any crashes or downtime while it was hosted in the cloud. While occasionally one or two queries may take longer due to network lags, these issues are more infrastructure-related since I have never faced any problems with Elastic Search's stability, which generally retrieves information instantly.

Regarding scalability, I consider both vertical and horizontal scalability in theory. I have not experienced sharding but find it interesting as a use case with Elastic Search. I see significant potential for vertical scalability, which can accommodate more data and offer substantial improvement.

When discussing initial deployment, the specific attribute of interest is the overall initial installation when starting to roll out the product. The deployment was a struggle as I faced challenges with bash commands and understanding how to run things on my system. Looking up tutorials on YouTube was tricky, and cross-referencing with documentation posed difficulties as some people customize setups to their needs. Setting up MySQL is straightforward, while with Elastic Search, I had to run bash commands for proper service execution. I faced some hurdles getting CRUD queries to work correctly. I resorted to Docker as an alternative, which diverged from standard practices of creating a local database service. An ideal setup would include a setup executable for Windows that would greatly facilitate immediate access and CRUD operation starts.

In my case, the system was already running by the time I started, as the custom DevOps team managed the deployment, and I was only tasked with connecting via Kibana and issuing bulk insert commands.

I have not checked Elastic Search's pricing thoroughly, so I do not know how a company would perceive it. From what I see, small companies might consider the cost, with starting pricing for a single node instance at $16 a month for serverless and hosted options, though at least one or two connected clusters would be necessary for viable solutions. Companies might see this lower end pricing as suitable, but for startups, reaching up to $2,000 could appear steep, depending on their aggressive usage approach.

I faced a situation where our graph database work halted due to technical difficulties with the Neptune product, as some CRUD operations were not carried out. Product specialists suggested that the business case did not fit the graph database's requirements and recommended Elastic Search instead for a better use case. I was involved in a data structure related to car spare parts needing to facilitate purchases by linking parts to various car makes across catalogs, ultimately attempting to shift from relational databases due to overwhelming data generation that slowed down indexed lookups. Elastic Search significantly helped in confirming order data lookup, but costs for clusters in further development led to work being stalled.

A preliminary architect consultation or proof of concept on cluster purposes would aid in establishing understanding for further development on Elastic Search, which is becoming increasingly costly in the cloud due to demand. A structured understanding of costs tied to usage metrics would greatly assist in planning before commitments, as delays in our POC adversely affected our progress. Documentation should also encompass potential use cases and scenarios to better assist developers during implementations across programming languages to ensure seamless integration.

Regarding alternatives, I have worked with various database products, including Azure technologies where I worked with NoSQL storage tables similar to AWS DynamoDB, which are schema-less with varying attributes per record. These use partition key and row key for accessing information, fragmenting what we associate with traditional RDS. Additionally, I worked with Axelor CRM from a French company, alongside MySQL and Oracle. My first company used MS SQL, and I have discussed my use case involving AWS Neptune graph database and Elastic Search, which encompasses all I have worked with so far.

For an overall rating of Elastic Search, I would score it at a solid 8 out of 10.

Its speed has facilitated my understanding of logical operators and streamlined query issuance. I would love to grasp the inner workings of sharding with distributed schema implications. Based on what I have experienced thus far, I find it a significant improvement, but once I better understand sharding and its performance effects, I would likely adjust my score.

My experience with the relevancy of search results using Elastic Search indicates that issuing a full query yields a finite number of results, while partial text searches can return irrelevant information. Mastering query issuance with Elastic Search is a valuable skill that develops over time. I prefer a structured JSON approach, utilizing properly sequenced clauses, which allow drilling down to a limited set of records that directly relate to the search context.

On hybrid search effectiveness, I think that AI is progressively offering more concise information. Providing more relevant keywords allows Elastic Search to generate results faster than other databases, such as RDS. The ability to engage with text directly simplifies understanding records and has a significant impact on AI functionality in rendering accurate results based on user needs.

Public Cloud

Amazon Web Services (AWS)