Details:
I recently provisioned an Elastic Serverless instance on GCP (asia-south1) purely for learning and experimentation. My usage has been extremely minimal:
Only one record stored in a single index.
At most one search query executed in a day.
No continuous ingest, dashboards, or production workloads.
Despite this, I am incurring charges of around ₹200–₹300 per day (~$2.3–$3.5). On reviewing the billing breakdown, most of the cost appears to come from ingest VCUs, even though I am not actively ingesting data.
I discovered that:
Default system indices (alerts, Kibana event logs, observability assistant) are created automatically, each with a 5s refresh interval, leading to thousands of refreshes per day.
My own index initially had a refresh_interval of 5s, which I later set to -1 to disable auto-refresh.
Even after disabling auto-refresh, I still see costs accumulating, likely due to background tasks or system indices.
Problem:
For a minimal learning workload with negligible data and queries, the daily cost is unexpectedly high. I did not anticipate that default system indices and refresh behavior would generate such significant charges.
Request:
Clarification on why ingest VCUs are consumed at this scale despite minimal usage.
Guidance on how to configure or disable system features (alerts, observability, event logs) to avoid unnecessary costs.
Confirmation whether Elastic Serverless is suitable for low-volume learning/testing scenarios, or if a different deployment model is recommended
. I have also attached an image below. According to the internet, 1ecu is 1 dollar, so for my learning basic index setup cost 10 dollars in 4 days, why please explain
What is the goal of your learning and experimenting? If you are learning about Elasticsearch itself and the associated tools I would recommend installing it on a laptop or desktop as any cloud usage comes with charges. I would only use Elasticsearch Serverless if I was investigating features or constraints specific to this deployment method.
I am trying to learn about billing and costing. If it’s charging me 2 dollars a day for single collection and single record and a few searches a day, then there is no point in learning, as I am never shipping this expensive search engine
my use case is learn and use this for my prod app , as you know in prod app ,there will be thousands of records and mutiple index so if i am getting this much charge for basic usage then how am i suppose to use this search in my prod app , bills will sky rocket
If you are learning about Elasticsearch I would recommend spinning up an instance on your laptop. Once you know what features you will use and what usage, access patterns and data volumes will look like it makes sense to compare different ways of getting access to Elasticsearch, where Elasticsearch Serverless is one of the options. This is the reason I was asking about details of the application you are considering powering with Elasticsearch.
Learning is good, and I hope you get clarity on the costs. But there is a basic issue with your methodology, here's an analogy. How much will it cost to run a car if I drive 3 km per day? The costs will be dominated by insurance, road tax, leasing the vehicle, parking, ...
You cannot multiple that by 100 to get the total cost if you were to drive same car 300km per day, where the petrol/diesel/charging costs likely become a much more significant element.
Thank you for your multiple attempts to respond, but I must reiterate with extreme clarity: Your recommendations to "spin up a free local instance" or "learn the features" are non-responsive and fail to address the fundamental financial barrier to adopting Elasticsearch Serverless for our production application.
My core use case is not about learning; it is about cost-effective scaling to production. The current cost structure makes this impossible.
1. The Concrete, Irrefutable Financial Issue
My simple, low-volume learning/testing environment consumed 12 Elastic Consumption Units (ECU) in just 4 days.
ECU Value: As 1 ECU nominally equals $1.00, this is an approximately $12.00 charge for a basic test/dev environment in four days.
Production Scaling Failure: This equates to a projected monthly cost of approximately $90 (12 ECU / 4 days * 30 days) just for a basic, low-volume development workload. For a future production application with:
Thousands of records.
Multiple indexes.
Consistent search and indexing traffic.
The bill will be prohibitively expensive and orders of magnitude higher than expected. If I cannot get a concrete answer for this basic usage costing, I cannot proceed with this platform for production.
Thank you for the time and insight you and the team have provided so far on the Serverless pricing model and the fixed-cost analogy.
I apologize if the tone of my recent emails was overly insistent or demanding; I was primarily focused on obtaining specific financial details to justify a production decision, which is a high-stakes concern for our team.
Since we still lack the necessary clarity and fail to fully understand the cost drivers for the Serverless model, particularly the consumption floor for low usage, we will unfortunately have to move on from this option for our production environment.
This is why I was asking about your use case. If you truly are expecting very low data and traffic volumes maybe using a hosted Elasticsearch service of any kind is not a cost effective option at all as there is overhead and these services may not scale down to the level you are expecting.
If you provided the details I asked for we may be able to find other more cost-effective options that you can consider.
That was my analogy, I don't claim it's perfect, even good, and I don't speak for Elastic in any way whatsoever. But you did seem to ignore the "dont scale costs linearly" point.
IMhO you should wait for responses from Elastic staff, as you have essentially a sales query.
We are evaluating Elastic Cloud Serverless for our e-commerce platform's search functionality, driven primarily by the pay-as-you-use pricing model and the significant reduction in operational overhead/maintenance.
The serverless model is highly attractive to us as we aim to launch with minimal infrastructure management, ensuring our technology can seamlessly scale to handle future growth without requiring a fundamental architectural shift.
We require a cost estimation based on two distinct scenarios: an initial low-volume starting point and a high-scale projection to prepare for the worst-case scenario.
Use Case and Scenarios
Application Type: E-commerce / Product & Service Search (Full-Text, Geo-Search)
Initial / Low-Volume Estimate (Minimum Expected)
Indexed Documents: 50,000 Products/Services
Total Registered Users: 5,000 Users
Concurrent Active Users: ~50 Active Users
Data Ingestion Rate: Low (e.g., 5-10 updates/hour)
Concurrent Active Users: ~10,000 Active Users (Peak)
Data Ingestion Rate: Moderate (daily product updates)
Search Queries/Day: High (e.g., 1,000,000 queries/day)
Specific Questions for Serverless Costing
Low-Volume Costing: Based on the Initial/Low-Volume Estimate, what would be the approximate monthly cost for a Search use case on Elastic Cloud Serverless? We want to ensure the "pay-as-you-use" model is indeed cost-effective for a very small starting operation, without significant hidden minimums or overhead.
High-Scale Costing (Stress Test): Based on the Max/High-Scale Estimate (1M documents, 10K peak active users, 1M QPS estimate), what would be the projected monthly cost? This is crucial for long-term planning and ensuring the technology's cost scales sustainably.
Pricing Breakdown: Could you provide a clear breakdown of how the Elastic Consumption Units (ECUs) or Virtual Compute Units (VCUs) for Search and Ingest would apply to these two scenarios, specifically referencing the pricing for:
Ingest VCU (for indexing the 1M products)
Search VCU (for handling 1M daily queries)
Search AI Lake Retention (for the data storage of 1M documents)
We are confident in the Elastic Stack's capabilities for search but need to validate that the Serverless offering aligns with our requirement for low operational burden and a cost-effective, consumption-based model from day one up to maximum projected load. – This is as detail as i can go please let me for my use case am looking at the right product
We did some debugging and I'm afraid you're hitting a bug (that's the bad part). You have a tab with Kibana open, right? Which does some automated requests (those made sense for a stateful service but not a stateless one).
The good part is that we were already working on it and just opened a PR to fix it. I hope that this will land soon and you won't be having the issue any more.
ok, I won't open the Kibana live tabs completely today and check if the costing has any impact. Can I still use my localhost Kibana to connect to serverless Elasticsearch (need steps to do so), or is the same bug present on localhost as well?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
