[benjaminwootton]

I think they key with usage based pricing is to have the right units.

I’m in the data space and a company like Snowflake has a model where you pay for compute by the second and storage by the byte. Very simple, transparent and everyone is aligned.

Some other database companies try this though and it feels very opaque. When you get into an enterprise sales cycle and pricing negotiation, they try to build a price based on data ingested with big steps up at each tier. I really hate the opaqueness of that model combined with bespoke pricing.

Some of the ETL companies have tried to charge by number of rows loaded. That just feels too arbitrary to me, more disconnected from value incurred and quite risky.

I see a lot of this from the buyers side and I think the wrong consumption based pricing models holds back a lot of these companies. I know of $millions which would have been transacted on a more flat fee basis even if the net cost was likely higher.

[OJFord]

> pay for compute by the second and storage by the byte. Very simple, transparent [...] Some of the ETL companies have tried to charge by number of rows loaded. That just feels too arbitrary to me, more disconnected from value incurred and quite risky.

Did you typo that the wrong way around? #rows seems way more connected to 'value incurred' for ETL than compute time to me. 'We help you load data, you pay by how much data you load' vs. 'we help you load data, you pay by how long it takes us'!

[IanCal]

Rows isn't the amount of data, and it has no link to how complicated it is to create/verify/store. I'd rather pay by time & actual storage.

Want to load a billion tiny rows of super simple data into snowflake? Cheap. Create a table out of really tricky nested joins/complex comparisons? Expensive.

[cryptonym]

> I’m in the data space and a company like Snowflake has a model where you pay for compute by the second and storage by the byte. Very simple, transparent and everyone is aligned.

Not sure everyone is aligned. Sounds like Snowflake got no incentive on optimizing queries. They even got an incentive doing the opposite. They must keep their infrastructure as-is without any optimization on compute time nor storage to earn the same amount every month.

[fphhotchips]

Snowflake employee here, not speaking on behalf of the company.

Short version is that you would think so, but it doesn't work that way for at least two reasons.

1. If we weren't investing in product optimization, but our competitors were, we'd quickly be outpaced.

2. When we invest in optimizing queries for our customers, the ROI on the Snowflake investment goes up. This results in actually getting even more money than if we just didn't bother, because CFOs that see great ROI on an investment absolutely do not hesitate to throw more funding at that investment. Making the denominator smaller is a really fast way to make the ROI higher.

So while the incentive seems to be perverse on first glance, very quickly it becomes clear that this isn't the case on further analysis.

[philjohn]

Was a heavy Snowflake user at my last company - and this is what we saw.

Plenty of profiling tools to show why a query was taking a certain amount of time allowed us to optimise things, and also, the product seemed to get quicker over time.

Also love that, unlike BigQuery, you charge by compressed data size, not uncompressed data size.

[BXlnt2EachOther]

The next day, it looks like BigQuery started charging by compressed data size. Any opinions on Adobe bringing back perpetual licenses? Or... do you have any stock tips?