Elastic Search Reviews

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

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

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

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

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

The customer support for Elastic Search is quite good.

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

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

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

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

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

Elastic Search is stable.

The customer support for Elastic Search is quite good.

I would rate the customer support a nine.

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

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

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

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

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

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

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

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

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

Public Cloud

Microsoft Azure

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)

I have implemented Elastic Search in my organization. My experience has been really good with Elastic Search regarding the dashboards and alerts. They have integrated AI/ML capabilities in it. The Attack Discovery feature helps to dig into incidents from where they occurred to determine how the incident originated and its source. It gives an entire path of attack propagation, showing when it started, what happened, and all events that took place to connect the entire cyber incident.

Another feature is image vector analysis, which can authenticate images to prevent impersonation frauds in the ecosystem. This is a major use case in personal information and identifiable information portfolio.

I'm using Elastic Search as an observability tool and a SIEM tool. The indexing, searching, fast indexing, alert mechanisms, and BCDR compatibility are pretty smooth with Elastic Search.

On the resourcing part, I have cut off a good amount. While I don't have a concrete percentage to mention precisely, it has reduced resources to some extent.

Attack Discovery is the first feature that I appreciate. It is truly an amazing feature for any SIEM to have inbuilt. The image vector analysis is another feature that identifies any manipulation done to images. It can authenticate and identify authenticated images. If there are 10 duplicate and forged images, it can identify them through vector-based searching capabilities. These two features are prominent in terms of SIEM capabilities that Elastic Search has.

I can share feedback from the SIEM perspective about Elastic Search, as I had evaluated Elastic Search, LogRhythm, QRadar, and Microsoft.

More AI would be beneficial. I would also appreciate more simplicity in dashboards. A comprehensive dashboard is something I could expect.

I have been using Elastic Search for a year now.

There are no limited parameters to search from the events perspective. When you put one keyword, everything related to that keyword in your ecosystem will showcase all the results. This helps to get into the granularity of any events happening across the system.

It has gained significant visibility. Comparing alert statistics from other SIEMs where they could trigger 50 alerts on average weekly, Elastic Search has given me alerting statistics of roughly 90 plus for a week's time. All those alerts are mapped to MITRE ATT&CK framework. Though it could result in false positives in the earlier stage until you fine-tune and streamline the use cases in your SIEM, which is common with all SIEM tools, the visibility that Elastic Search has given us is amazing.

It was a direct purchase.

Positive

We previously used an on-premises solution.

The setup complexity depends upon the engineering team doing the implementation and the kind of infrastructure you have where logs will be ingested into the solution. For us, it was time-consuming in the earlier stages, but it was manageable and not overly complex.

We have seen moderate returns on investment.

As a CISO, I review and do the governance part. I receive alert notifications, but I don't work directly with the tool. None of my team members have complained or proposed any feature changes or modifications to the existing solution.

It totally depends upon the nature of business you are in. For my organization, it was imperative to have image scanning in place and identifying frauds happening with PII. From that perspective, Elastic Search has played a vital role. It has good inbuilt EDR capabilities as well, making it a good-to-go tool.

I rate Elastic Search eight out of ten.

On-premises

Other

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

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

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

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

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

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

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

I haven't seen any downtime.

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

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

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

Positive

The initial setup process took around a month.

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

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

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

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

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

I would rate this solution an eight out of ten.

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.

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

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

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

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

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

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

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

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

In my experience, Elastic Search is quite stable.

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

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

Positive

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

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

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

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

Private Cloud

Amazon Web Services (AWS)

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.

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

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)