Cloud event store expensive

Hi all

I am finding that Azure cloud event store production is super expensive. Seems better hosting in vm…

Am I right or wrong?

I agree.

Currently the smallest available production-grade option is M16 and a 3-node deployment with 1TB space currently costs $1,867.35 / month in West Europe.

We have a very similar self-deployed ESDB cluster on Azure with 3x D4s v5 & 3x 1024GB Premium SSD disks and it costs around ~$950 / month.

Some difference in cost is of course expected as there is a shift in responsibility (SLA, backups…etc.) but I totally agree that it seems a bit steep.

TCO might seem to be 950 indeed for your machines :
but does it take into account
Monitoring , keeping secure, adding features, …
paying the SRE team members 24/7, to keep everything running ( incl when cloud providers go down)
paying the support people .
paying the DB engineering people to add & maintain features ( to the DB & cloud offering ) …

@yves.lorphelin even with that Azure Cosmos DB is still cheaper and has more features. CosmosDb also has a change feed.

so ?
Does that change the TCO for you when you take all into account ?
Btw ESDB change feed exists as well, it’s the primary consumption model when talking about event storage engines

I am sure the surcharge of Event Store Cloud is not 100%. If you observe 100% price increase, it must be related to the machine size and type.

Sometimes people compare incomparable things. I remember someone mentioned B1 machines and compared with our C4 price, forgetting that B1 are dev grade burstable VMs that should never be used to host production databases. We only use similar mVM type for F1 in Azure and it’s quite inexpensive.

I can also add that being on Azure and complain about prices is somewhat contradictory. Azure is not cheap on its own, and it’s by far not the best public cloud.

Lastly, comparing CosmosDB prices is more apples vs oranges discussion. VosmosDB has a different hosting model, it is priced based on volumes and throughput, not based on physical resources. More down to Earth comparison would be with similar offerings like Mongo Atlas and Elastic Cloud as they have similar deployment modes.

1 Like

I have provided my exact configuration for price comparison. 4 vCPU cores & 16G of RAM with the same disk size and instance count. This probably is not 100% of the cost, it does not include data transfer and backup storage …etc. But I’m sure I have covered the significant portion of it.

Don’t get me wrong, I’m not saying that this should be Event Store Cloud’s cost. As I have stated before, I understand the cost of monitoring, backups…etc., i.e. the overall cost of database management responsibility. I still think the difference should be lower.

I think a better comparison than CosmosDB is MongoDB Cloud. They provide a similar managed database service and deploy it on Azure and peer it to our network. We have a 3-node 4 vCPU & 16G of RAM MongoDB cluster managed by them, and it costs us ~$1000 / month. The only difference is disk size here, we currently have a storage size of 64G. But I can use 64G of disk space because it auto-scales. If I had the option of autoscaling disks for ESDB, I would not try to deploy 1TB of it. If I choose 1TB of space for MongoDB also, it would cost us around $1600 / month.

So one major problem for cost here is we have to specify an inefficient amount of space for ESDB if we don’t want to migrate our data to a new instance with larger disk space in foreseeable future. Even if our data is around 100GB, we pay for the full 1TB backups…etc.

Our current ESDB disk space used in production (sum of chunk files) is ~260G. I would expect it to go over 750G by the end of 2022 with our current growth rate.

So if I had the option, I would probably choose a 300G of disk space with autoscaling disk option enabled for Event Store Cloud.

The disk space is not used for backups. All the backups are stored as blobs and do not use the disk space of cluster machines.

Concerning the disk size scaling, Azure is the only cloud provider that requires detaching the disk from the machine to change its size. Logically, it also requires taking down the machine. It requires orchestration from our side, which is something we are working on atm. As soon as it’s done, no-downtime upgrades, vertical scaling and disk size change on Azure would be possible.

If you check AWS and GCP, we provide zero-downtime disk resize as those providers allow it natively.

Thanks for the reply.

Looking forward for that feature to be enabled on Azure also then.