4 ms·
Until you have ran your full etl load in snowflake or bigquery, you can never estimate the cost. You may answer some questionnaire about your projected usage, d
by higeorge13 4y ago
Until you have ran your full etl load in snowflake or bigquery, you can never estimate the cost. You may answer some questionnaire about your projected usage, data volume, frequency, etc. but until you execute all your models with any warehouse you can estimate nothing.
Usage based pricing is fine when it’s on predictable metrics, number of logs sent, number of rows sent, number of emails/sms/etc sent, number of seats, users, licences, etc. When it’s on abstract terms like credits or abstract resources like warehouses (with no idea what resource a medium warehouse utilizes) or error prone metrics like scanned gigabytes per query, it might become problematic at some point.
- lupire 4y agoCharge for what you sell. Do you sell RAM and CPU, or do you sell data processing? Which do your customers prefer? How do the model their need?
- higeorge13 4y agoThis is true, but my point is that it’s not predictable. e.g. I have 1 TB db with 50 tables and a specific i/u/d pattern. Until i replicate the whole db incrementally and run this with some warehouse, there is no way i can make an estimation about #credits per year. I want to add some new big dbt model? There is no way i know how much time will a warehouse be running because the query planner cannot create a sensible query execution plan. And so on. Charging e.g. by # of processed rows is more predictable from end-user/admin perspective. That’s all. But obviously they make more money the way they price, what do i know? :-)
- BillPalombi 4y agoTotally agreed - vendor specific constructs like credits are particularly opaque. They burden the user with the complexity of managing cost without clear levers that directly correspond to a known metric describing their usage.