Hacker News Reader

Comment by Nifty3929 | Hacker News Reader

Not necessarily. Combined with the move to compressed storage, really they're shifting the cost from storage to compute. Storage heavy customers may see their cost go down. Probably this just better aligns the pricing with the cost model.

You might also see a bit of savings by using Autoscaling which wasn't available before.

Net/Net it depends on the specific usage pattern whether your cost will go up or down.

The per-GB price for compressed is higher, but more than offset by the fewer GB being measured, depending on your compression ratio. If the per-GB price doubles and your compression ratio is 8:1, that's a 75% reduction on the storage side.

View on HN

For my company, compute is over 80% of the cost, so we would come out much worse on this even if storage dropped to zero.

You started with “not really” but then clarified that it does indeed change the costs to the worse to an unquantified fraction of its customers, so what you should have said is “yes really” both literally and figuratively.

No, he started with “not nessesarily”. Words matter.

The article already clarified that not every user will see prices double with the use of “many” rather than “all.”

Thus saying “not nessesarily” changes what? It’s like saying you’re wrong and then repeating what someone said.

Aggressive equivocation.

Good call out, goalpost shifting is one of the primary reason why discussion quality is as poor as it is on the internet.

I guess spelling doesn't, though...

Title is intentionally misleading even if it's technically accurate (given that "many" has no technical meaning).

Yep. "Many Americans are killed by lightning every year!" Technically true, but obviously sensational.

What's sensationalistic about that? It seems accurate and not loaded to me. "Many" just means "more than a few" and implies "less than a majority".

I wouldn't consider 28 "many" in a context where it's less than one in a million.

(https://www.cdc.gov/disasters/lightning/victimdata/infograph...)

That is the point that gp is making. Many has no definition and many (see what I did there?) disagree about where it’s appropriate.

I don't think it's even technically true in the lightning case

We’ve achieved recursion.

Edit: how can something be “technically” true if the word has no definition?

I said 'many' because 'everyone who uses reserved capacity instead of on-demand pricing' was too long for a headline.

Thats why comments allow more characters. Editorializing belongs in comments.

Anyone who uses reserved capacity will see their prices double?

That's still not true.

You should be particular about the words you choose to be particular about because those words weren't said.

the title of this post is very editorialized and biased. Why didn't the OP just post the actual title of the announcement?

Compression based pricing is huge for data warehousing loads and will save clients quite a bit of money.

And think of it on the positive side, at least they didn't cancel the product in this announcement! Yet!

As someone responsible for pricing decisions at my company, it has been very interesting reading through this thread and processing the reactions.

First, I will say that - I feel for users that are reading this blog and trying to process the changes. I completely understand the reaction of those to whom at a glance it may appear that compute bills would go up by 2x as a result of this pricing change. I am sure that is shocking, especially to companies on short budgets. The change is effective on July 5 2023, which is really not that far away. If you have a mature data warehousing deployment, it could take may way longer than 3 months to plan and execute a migration.

However, speaking from experience, it is challenging to come up up with a perfect usage-based pricing model for infrastructure heavy product like BigQuery that suits everyone’s needs, and even harder to communicate it well.

Some of the reasons are…

* There is tension between keeping the pricing simple and yet have it be fair to every workload. If you really want a fair pricing model, you will need to add more and more pricing dimensions to make users pay more granularly for each resource that makes up the infrastructure cost. But a pricing model with 10-20 dimensions is really hard to understand, even if the final price tag would have been lower for each workload, than a more “simple looking” model.

* Deciding on pricing changes of an existing offering is also not easy. I am going to guess the reason for this pricing change wasn’t because Google decided to “nickle and dime” their users (could be of course, but I would hope that is not how most companies think). I would guess it was the autoscaling feature that was the catalyst for the change. Why did the compute price point have to change? Probably because current users are over-provisioning by quite a bit and the current price point is lower to reflect that, so the end price tag is still within reasonable budget and market expectations. If the autoscaling feature is going to work as perfectly as their charts in the blog show, the price point must come up to make up for the margin loss. As some point out, in that scenario, bursty compute workloads that are reserving too much capacity may actually come out ahead.

* Once you do one pricing change, you may as well bundle in other important pricing changes that have “piled up” on the product team backlog. I am guessing that is how the storage change came up - users were confused about paying for uncompressed storage, while some alternatives charged on compressed, and so they made the change. Changing pricing from one dimension to another is tricky. As some pointed out, storage price point went up, but the dimension moved from uncompressed to compressed storage, so the effective price change for most users may actually be lowered, if the compression rate make up for the price point increase.

Anyway, very interesting, I am really curious to see how this change plays out in the market in the coming months.

Reply on news.ycombinator.com