Launch HN: Dashdive (YC W23) – Track your cloud costs precisely

I think you are swimming adjacent to usage-based pricing products like stigg. They also keep track of usage, and though their focus is not on what it costs you, that follows readily from usage.

Are you thinking of expanding in that direction, or integrating with such products? I would look favorably at a product that combined pricing (them) and observability (you). You're solving basically the same problem; don't make me buy two products.

How do you aim to attribute cost for multi-tenant services like databases?

For example, if I have a database costing $100/m, and 4 equal sized customers (by data volume, compute, requests), you could say that each is costing $25/m. However if I'm over provisioned by 50%, then an incremental user is only actually $12.50. To understand this difference requires understanding resource utilisation, which particularly for compute can be really hard. There's also a difference between desired headroom (for redundancy) and undesired headroom (due to inefficiencies), and these will be nuanced per company or service deployment.

This could also be taken in reverse – rather than the cost for an incremental user, the savings from removing a user. Given 2x $100/m databases with 2 customers, one accounting for 60% and one for 40%, losing the larger one would allow a 50% reduction on cost, but losing the smaller one would not.

What's your thinking here? Are you trying to communicate the incremental cost of a user? Are you trying to communicate the cost of a user against the current infrastructure, whatever that infrastructure might be?

Excellent points. Now that I think about it, I think the two products are naturally offered together, because usage-based pricing should be based on underlying costs, monitoring which is what you provide. If you had better visibility into your costs, you could set usage-based prices, and price tiers in a more principled manner.

You're right; it's a bit inaccessible at the moment. We're planning to offer a more affordable tier in the next 1-2 months. A bit more context here: https://news.ycombinator.com/item?id=39178753#39186948.

TL;DR - We treat the per-customer usage data as the ground truth, and the per-customer cost can vary based on parameters chosen by the Dashdive user and their preferred mental model.

At a minimum, every customer is assigned the cost resulting from the usage that is directly attributable to them. This "directly attributable" figure is obtained by "integrating" vCPU-seconds and RAM-seconds on a per-DB-query basis, per-API-invocation basis, or similar. For example, if Customer X used 5 vCPU seconds and 7 RAM-GiB-seconds due to queries over a period of 10 seconds on our RDS cluster with total capacity 1 vCPU and 2 GiB RAM, then they directly utilized 50% of vCPU capacity and [7 GiB-sec / (2 GiB * 10 sec)] = 35% of RAM capacity over that period.

The question remains of how to distribute the cost of the un-utilized capacity over that period amongst the customers, perhaps distributing some portion to special "desired headroom" and "undesired headroom" values. As you mentioned, the answer is subjective and can vary between Dashdive users (or even over time for the same Dashdive user, e.g. a user decides they can reduce their desired headroom from 30% to 20%). The only sensible approach in our opinion is to make this configurable for the user, with sane and explicit defaults.

Let's go through both your examples to illustrate. In example 1, each of the 4 equally sized customers would be assigned only 12.5% of the total cost of the cluster. The dashboard would show that, by default, 30% headroom is desired, so out of the remaining 50% capacity, 30% would be marked as desired headroom, and 20% would be marked as undesired headroom. The user can override the desired headroom percentage. Although in our opinion it is most correct for all headroom to be treated as a fixed cost in multitenant scenarios, we would also provide the option to distribute both/either headroom types amongst all customers, either proportionally or equally.

For example 2, our model is not sophisticated enough to capture the nuance that losing only the larger customer would allow cost reduction. Assuming both customers used both databases (let's say they're replicas or shards), and 0% headroom, we would simply assign 40% of costs to the smaller customer and 60% of costs to the larger one. This is subtle, but the missed nuance is only important if $100/m is the finest-grained resource you can get. Otherwise, if you lose the 40% customer, you can switch to a 2x $60/m DB, for example.

This is a very astute callout! It has come up a couple times as a point of concern from prospective customers. Would be keen to hear if this diverges from your expectations at all.