Thanks, I quickly went through how Aurora performs IO metering. It divides IO into Read operations and Write operations, which seems suitable for OLTP services. However, for analysis purposes, there is also CPU consumption that cannot be ignored. Would it be a good idea to include Calculate operations similar to IO?
I'm pretty confused about what you are asking. In the original post you made it sound like you don't want to consider CPU and RAM, and in this response, you do.
You could also look at how AWS Lambda does it. They have a standard base configuration, and for that one, you only pay for invocation of a function, and that function has to finish in some period of time before it's killed. If you want more RAM, or more CPU, or same CPU but more time to finish calculation, you pay above the baseline.
Also, it's not obvious to me that the Calculate component cannot be ignored. AWS Redshift Serverless and AWS Athena are all OLAP, and they all operate on a "data scanned" metering model, no CPU or RAM considerations.
Also - I am mostly familiar with AWS, so that's what I am suggesting here. Obviously you and AWS have completely different scalability considerations, so this might not apply at all. But, if you wanted to be competitive, then in the end you'd have to be better than AWS on price, so starting there is not a bad idea, even if in the early days you are doing something different
Apologies for any uncertainty regarding CPU and RAM factors. Initially, my thought was to decouple the cost model from conventional hardware factors from a user's view. However, from the service provider's viewpoint, I have to encompass aspects like CPU consumption, IO usage, and RAM utilization while crafting this cost model to bring mutual benefit.
Utilizing AWS as a foundational reference is indeed a worthwhile approach, something I'll delve into by examining pertinent services.