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.

Elastic Search is normally used for full-text search where users are fully depending on it for searching by name, address, and similar fields, and we need to gather the data with good latency, so we normally prefer to save it into Elastic Search.

Elastic Search helps for full-text search because we normally use it for keywords and other related terms. If there are keywords and searching requires numerical data and other elements, we prefer RDS over Elastic Search. However, if it is regarding complete full-text search in which we cannot do any kind of indexing and it is very difficult, we prefer Elastic Search.

Elastic Search's best feature is that it is very convenient to save, plus it is schema-less, and it has very good latency and also provides us with different kinds of mapping strategies which allow us to optimize many things according to the data structure. It is a kind of non-structured and structured mix.

The benefits of using Elastic Search are mostly for two to three purposes. For logging, it is very easy to insert the logs into Elastic Search and start searching it using Kibana, and it is very easy to make visualizations over there. The second purpose is that we normally use it for views. If we have searches from the front end with a specific structure, it is very difficult to go to a different table and create the query in the database, so what we do is sync our database with Elastic Search and create a view on Elastic Search which will give us the result in milliseconds. This is how we are currently utilizing it.

Elastic Search has an annoying limitation regarding page size. It has a specific limit for queries on Elastic Search, and the default is ten thousand, and we can increase it. However, after increasing, it can slow down. Pagination in Elastic Search is very slow. If I need to parse one million records saved into Elastic Search, it becomes a nightmare because I need to do the pagination, and it is very problematic in that regard. I need to do ten thousand records and then go to the other page, and when going to the other page, it currently takes much more time than RDS. For specific cases, if we need to do full-text search and searching for one specific word returns less than ten thousand records, it works very well. However, if we go for more than ten thousand, then it creates an issue for us.

It has been almost ten years since using Elastic Search.

Elastic Search receives a stability rating of nine point five; we rely on it.

In terms of scalability, for the managed service, it is very easy, but the scalability aspect is a bit tricky. Scaling up Elastic Search cluster requires a bit of time because of sharding and replications. It takes more time since it needs to copy the data. For example, if we are working on three nodes and adding a fourth node, the synchronization process will occur in the middle, and the higher the data volume, the more time it will take. Scalability is rated around five to six.

Elastic Search's technical support receives a rating of eight.

Previously, we were using the AWS managed cluster on the cloud, but now we have created our own. On the same cloud, we have deployed Elastic Search on our EC2 machines, so it is self-managed, not on-premises. On-premises would be if we give the solution to somebody else, then we would deploy Elastic Search on their specific cloud, but we only deployed it in our system.

I did not go into the deployment part of Elastic Search because it is a DevOps matter. I was in a senior role, so I sent the request and we received it. Normally, it does not take a lot of time if the person deploying is capable; it does not take more than two to three days.

We have about twelve specialists.

I cannot say much about the return on investment part because we normally work on a use case basis. If we find some kind of issue in our database which is currently taking time, then we need to shift to Elastic Search, and it will start giving us very good results. On the cost-saving side, rather than increasing our RDS from a less cluster to a big cluster, we can create a specific separate Elastic Search cluster, and it saves our money on our basic structure while giving us much more performance. I cannot tell you the exact part on how much was saved with the calculation, and I cannot provide the numbers, but it saves our time on the debugging side. Using it on the logs and creating visualization is very convenient for us to search the log and identify the issue as soon as possible. This saves our time, saves the customer's time, and decreases the time to respond and resolve.

Elastic Search's pricing totally depends on the server. Managed services from AWS are used, and we have worked on a self-managed Elastic Search cluster. On the AWS side, it is very expensive because they charge based on query basis or how much data is transferred in and out, making it very expensive. That is why we moved to the self-managed option. In self-managed, it is very easy to handle. We do not think any kind of proprietary Elastic Search solution is required.

Elastic Cloud Serverless is not being used. The GenAI experience with features like agentic AI, RAG, or semantic search is not currently being used. Kafka Streams is being used for log instigation.

Elastic Search has many pros, but the cons of it are that it is not structured, and we need to put all the things which are connected into a single index. Therefore, we cannot use it for our base structure database, but we always use it for supporting purposes.

While part of Careem, there were hundreds of thousands of customers using the solution, and now that in a startup, the clients are no more than one hundred.

Elastic Search requires maintenance. We need to keep it updated because Elastic Search normally launches new features and versions on both Kibana and Elastic Search sides. We need to keep updated ourselves, and also, we need to do maintenance on the storage side. Normally, we use Elastic Search for timelines, saving all the data from beginning to end, so normally the storage maintenance is an issue, and we have to increase the storage time to time, but it is not related to Elastic Search; it is actually related to our use case.

There is lots of support for Elastic Search in different tools like Logstash which we normally use for integration, and there are other tools as well, but it is very easy and not a big issue for that.

The Attack Discovery feature is not being used. Big businesses cannot survive without Elastic Search because it gives us very good visibility and handles our use cases very well. If we need something reliable and trustworthy as a solution, then Elastic Search is the way to go, as it is an integral part of big solutions. The overall review rating for Elastic Search is eight point five.