I developed a chatbot with text summarization and question answering capabilities. I need to summarize multiple PDFs, and I have a database in Google Cloud Storage where I perform keyword matching with Elastic Search using exact keyword matching.

I have different clients, but I use Elastic Cloud (Elasticsearch Service) for one specific client. For that one job, Elastic Cloud (Elasticsearch Service) is the main tool because I am using an Elastic Search strategy instead of a vector database.

Scalability is valuable to me. I have 50,000 PDF JSON files that contain my metadata, and I am really glad to use Elastic Cloud (Elasticsearch Service) for this volume without any issues. From a startup's perspective, I would say that until 10 GB of storage, there is no problem whatsoever.

Application-wise, everything was easy to work with. I really appreciated their dashboard because everything was clear, and it was easy to implement.

Because I am pursuing a PhD and work under the university, my university has an agreement with AWS, which makes it essentially free and easier to use. In the AWS ecosystem, everything is connected and I can control everything without uncertainty about what is happening behind the scenes. However, when using Elastic Cloud (Elasticsearch Service), I connected it to Google Cloud but I am paying separate receipts. Over the last two months in October and November, I paid two separate invoices that are not connected to Google Cloud, which I did not appreciate.

Google Cloud has a nice interface that gives me full control of pricing and billing. I can see daily, weekly, and monthly breakdowns with bar charts, and I can track exactly how much I spent during any period. Elastic Cloud (Elasticsearch Service) does not have such a tool for billing visibility. Since I am handling significant amounts of money and am responsible for this task within my company, I have high expectations for pricing and billing transparency. I would appreciate the ability to set a spending limit, such as uploading 200 euros, and receive notifications when reaching 50% of that limit. These notifications could appear on the dashboard, in the application, or via email. It would be valuable to see a timeline of my spending.

I would characterize the pricing as somewhat expensive. I did not use competitors extensively, so I may have a bias about this. The pricing of large language models is not expensive—I use Anthropic's Claude or Google's Gemini, which are state-of-the-art models. However, I am uncertain whether I have a bias about Elastic Cloud (Elasticsearch Service) pricing. It is not extraordinarily expensive, but when I compare it with the cost of using large language models or Google Cloud storage, it is quite expensive.

A couple of days ago, the Elastic team reached out to me. We have been regularly using the service since April, and 10 days ago at the beginning of December, I deleted my hosted deployments because I did not like the idea of paying when I am not actively using Elastic Cloud (Elasticsearch Service). They informed me that there is a serverless option available. Before Christmas, I want to try it to see how it works, as I am uncertain about the serverless concept and whether it will provide the same functionality that I use with the hosted deployment.

I have been using this since April.

I have experienced no issues whatsoever in the last five or six months. Whenever I perform my searches, and because my application is active with clients using it, there has been no feedback about problems. During my tests, I did not observe any lag or delay.

I would give them a rating of ten. They were extremely helpful, kind, and communicative. Three people from the Elastic team spoke with me, and they were genuinely trying to solve the problem and understand my expectations. It was really excellent, and I recommend them highly.

I used the hosted deployment version, not the serverless option yet. The hosted deployment took me 10 to 15 minutes to set up. It was very easy and primarily involved indexing. I generated Python code on my local computer within minutes and pushed everything with the indexing. It took about 15 to 20 minutes total, though this is related to the size of my folder. I was indexing around 10,000 PDFs and creating metadata JSON files. The process was easy and fast.

I also use AWS daily in their ecosystem, which contains everything I need. I use Google Cloud primarily because of the pricing, as I must consider profit margins.

My team is small, consisting of about four or five people. On Elastic Cloud (Elasticsearch Service), only two of us work with it, but I am the one who uses it daily.

So far, I have not performed any maintenance.

Elastic Cloud (Elasticsearch Service) focuses on exact keyword matching. This means they do not address semantic similarity well. For example, if I use a word and then use another word with the same meaning in a sentence but not a synonym or similar word, Elastic cannot understand this semantic similarity, which is important for my chatbots. This is why I was using vector databases, as they focus on semantic similarity of words and tokens, whereas Elastic looks for exact word representation.

The team mentioned that hybrid search is an option. I have my own vector database that I use daily as a personal solution, and I could give hybrid search a chance, but I have not tried it yet.

I would rate my overall experience as seven out of ten. Two points are deducted for the pricing, which was higher than my expectations. The pricing has been significant over the last two months and was considerably more than I anticipated. My overall review rating for this service is nine out of ten.

The main use case for Elastic Search is mainly for log management.

I appreciate the indexing capabilities and the speed of indexing in their product, which demonstrates how quickly logs are collected and stored. The search capabilities are also valuable.

The architecture of Elastic Search could be improved as it is complicated for most general users to build up the environment and maintain the cluster.

Currently, I do not have suggestions for additional functions that could be added to the product.

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

I usually use Elastic Search on-premises, which introduces complexity in deployment. Using the cloud version would reduce the complexity of setting up.

I would rate the stability for Elastic Search as eight out of ten.

I would rate the scalability as eight.

I would rate technical support from Elastic Search as three out of ten.

The main issue is a general sum of all factors. Being based in Hong Kong means I can only assess the service in my region and cannot speak for other regions based on my experience.

I am currently working with multiple solutions including Elastic Search, Splunk, and Graylog.

The initial setup for Elastic Search is complex.

The real-time analytics capabilities depend on whether you use the paid version or open-source version.

I work with SME users of Elastic Search, though the solution can technically support enterprise customers.

I have not extensively used AI technology with Elastic Search.

I can recommend Elastic Search to other users.

The pricing for Elastic Search rates as four out of ten. Overall, I would rate Elastic Search as seven out of ten.

The primary use case for Elasticsearch is to serve as a non-SQL database platform to replace traditional SQL processes. It is used in situations where unstructured data needs to be studied and searched.

Elasticsearch has been helpful due to its ability to handle unstructured data effectively compared to SQL. It provides a fast and interesting search capability which is advantageous for our needs.

The most valuable feature of Elasticsearch is its convenience in handling unstructured data, making it easy to use.

Elasticsearch could be improved in terms of scalability. If the database becomes too large, its efficiency is not as good as SQL. Additionally, the initial setup could be a little easier.

We have been using Elasticsearch for about two to three years.

We have faced shutdown issues, but these are mostly related to problems with our own machines and not due to Elasticsearch itself.

Elasticsearch is not scalable when dealing with very large databases. The efficiency decreases for huge databases because it deals with unstructured data, which presents an inherent problem.

The initial setup is of medium difficulty since it requires some understanding of the disk and related concepts.

Elasticsearch can be expensive. It requires some support and unlocking of features.

I recommend Elasticsearch for anyone looking to build a simple database, as it should be a top choice.

I'd rate the solution seven out of ten.

Using real-time search functionality to support operational decisions has been helpful. However, it is not functioning correctly, as the real-time search consumes significant system resources.

The search feature is one of the valuable features of Elasticsearch.

There are areas for improvement in Elasticsearch.

The real-time search functionality is not operational due to its impact on system resources. There are some stability issues.

My overall experience with support was positive.

The initial setup is complex.

I do not have specific details about the implementation team. The process might require certain expertise.

The pricing is not cheap and is expensive.

I compared the differences between Elastic and other SIEM solutions.

I am more like an implementer than a customer.

I'd rate the solution seven out of ten.

We save credentials, new account information, logs from Palantir Panorama, Firefox logs, traffic logs, GlobalProtect logs from our servers, and Active Directory new users. We're still improving this, but not very fast.

I appreciate that Elastic Enterprise Search is easy to use and that we have people on our team who are able to manage it effectively.

We are keeping an eye on other products like QRadar and Splunk in case they offer features that would benefit our company.

We currently use the free version of Elastic Search for some of our logs. However, if we were to use it more extensively, we would need to consider the pricing of the paid plans.

Another area of improvement is stability.

I have been using this solution for five years now.

I would rate the stability a seven out of ten. We faced a few issues.

I would rate the scalability a seven out of ten.

We don't use the support because we use the free version.

We were able to handle the deployment ourselves. We have one administrator and three users for this solution. So, there are four people in total.

I use the free version. We use the free version for some logs, but not extensive use.

Overall, I would rate the solution a seven out of ten. The free version is not very useful.