9 ms·

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 c

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.

ramraj07 4y ago
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.
- TylerE 4y ago
  No, he started with “not nessesarily”. Words matter.
  - foobarbecue 4y ago
    I guess spelling doesn't, though...
  - Retric 4y ago
    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.
  - linster 4y ago
    Aggressive equivocation.
  - Aperocky 4y ago
    Good call out, goalpost shifting is one of the primary reason why discussion quality is as poor as it is on the internet.
- bagacrap 4y ago
  Title is intentionally misleading even if it's technically accurate (given that "many" has no technical meaning).
  - throwaway894345 4y ago
    Yep. "Many Americans are killed by lightning every year!" Technically true, but obviously sensational.
    - JohnFen 4y ago
      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".
    - jefftk 4y ago
      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/infographic.html https://www.cdc.gov/disasters/lightning/victimdata/infograph...)
      - Godel_unicode 4y ago
        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.
        jefftk 4y ago
        I don't think it's even technically true in the lightning case
        Godel_unicode 4y ago
        We’ve achieved recursion. Edit: how can something be “technically” true if the word has no definition?
  - 4y ago
- gabereiser 4y ago
  You should be particular about the words you choose to be particular about because those words weren't said.
kdamica 4y ago
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.
outside1234 4y ago
And think of it on the positive side, at least they didn't cancel the product in this announcement! Yet!
hn2017 4y ago
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.
tbragin 4y ago
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.

ramraj07 4y ago

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.

TylerE 4y ago
No, he started with “not nessesarily”. Words matter.
- foobarbecue 4y ago
  I guess spelling doesn't, though...
- Retric 4y ago
  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.
- linster 4y ago
  Aggressive equivocation.
- Aperocky 4y ago
  Good call out, goalpost shifting is one of the primary reason why discussion quality is as poor as it is on the internet.
bagacrap 4y ago
Title is intentionally misleading even if it's technically accurate (given that "many" has no technical meaning).
- throwaway894345 4y ago
  Yep. "Many Americans are killed by lightning every year!" Technically true, but obviously sensational.
  - JohnFen 4y ago
    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".
  - jefftk 4y ago
    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/infographic.html https://www.cdc.gov/disasters/lightning/victimdata/infograph...)
    - Godel_unicode 4y ago
      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.
      - jefftk 4y ago
        I don't think it's even technically true in the lightning case
        Godel_unicode 4y ago
        We’ve achieved recursion. Edit: how can something be “technically” true if the word has no definition?
- 4y ago
gabereiser 4y ago
You should be particular about the words you choose to be particular about because those words weren't said.

kdamica 4y ago

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.

outside1234 4y ago

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

hn2017 4y ago

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.

tbragin 4y ago

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.