Live data from Hacker News

PlanetScale increases plans to include billions of reads

planetscale.com

51–60 of 71 posts

Re: PlanetScale increases plans to include billions of reads

#51
post #50

Earlier quoted context omitted.

First of all, I agree there are gotchas. We have roadmap items that will eliminate this problem in the medium term. I do however disagree that this is any worse than idle RDS hosts sitting around when you have no traffic, costing you huge sums for a service that is basically `apt-get install mysql-server` on top of EC2.

A high but predictable cost is completely different from an unpredictable cost risk wise. Hopefully you are not running a company nor anything that involves risk taking.

he is the CEO lol

Re: PlanetScale increases plans to include billions of reads

#52
If PlanetScale just offered to reimburse any costs above the 99th percentile of normal operations it would be a great success. If their business model is dependent on people getting screwed by costs above the 99th percentile then they shouldn't be in business.

Re: PlanetScale increases plans to include billions of reads

#53

Earlier quoted context omitted.

This comment has to be higher up. This pricing is like a sword over the neck and drops when you screwup or the sql planner screws up.

First of all, I agree there are gotchas. We have roadmap items that will eliminate this problem in the medium term. I do however disagree that this is any worse than idle RDS hosts sitting around when you have no traffic, costing you huge sums for a service that is basically `apt-get install mysql-server` on top of EC2.

That is wasteful too, but deterministically wasteful. You know exactly how wasteful you are being and how much it will cost.. no surprises.

Re: PlanetScale increases plans to include billions of reads

#54
post #6

Worth noting "rows read" is not "rows returned". If you do 1000 full table scans on table with a million rows, you got a billion reads https://docs.planetscale.com/concepts/billing#understanding-...

They're not alone in this approach. BigQuery and DynamoDB also meter data usage based on the amount of data processed during a query.

Authzed[0] also does somewhat similar with SpiceDB[1], but charges based on query complexity for the levels of nesting in the graph traversal, rather than the actual number of rows affect. A flat query is easy to compute, thus cheap.

[0]: https://authzed.com/pricing

[1]: https://github.com/authzed/spicedb

Re: PlanetScale increases plans to include billions of reads

#55
post #5

This is a nice change. It looks like it used to be $15/mo per 100 Million rows read, $15/mo per 10 Million rows written. Now it's $1 per billion reads and $1.50 per 1 million writes. So the write pricing hasn't changed, but the read pricing has gone from $150 per billion to $1 per billion (a reduction of 99.3%). $1 would have gotten me 6.7M reads before the change and now a billion reads (150x more reads for your dol…

Thank you for your thoughts. We are continuing to iterate. Pricing in the serverless world is a new craft and there is lots to improve on. We were very excited to see other companies follow suit with serverless pricing models after our launch. A lot went into making this iteration on our pricing. We spoke to customers, we reviewed all of our billing to make sure that this would save money for nearly all of our custom…

GP had direct questions which you did not answer.

Re: PlanetScale increases plans to include billions of reads

#56

Earlier quoted context omitted.

This comment has to be higher up. This pricing is like a sword over the neck and drops when you screwup or the sql planner screws up.

First of all, I agree there are gotchas. We have roadmap items that will eliminate this problem in the medium term. I do however disagree that this is any worse than idle RDS hosts sitting around when you have no traffic, costing you huge sums for a service that is basically `apt-get install mysql-server` on top of EC2.

After that comment, I hope you have a CTO who keeps you away from the engineering decisions.

Re: PlanetScale increases plans to include billions of reads

#58
post #6

Worth noting "rows read" is not "rows returned". If you do 1000 full table scans on table with a million rows, you got a billion reads https://docs.planetscale.com/concepts/billing#understanding-...

I still don't see how this pricing model is usable in a database with a query planner. The user is not in control over the query plan, the database is. This is a recipe for disaster, and I'd never feel comfortable with this. Even with good understanding of how the database works there is pretty much no way to ensure that the database doesn't do some suprising full table scans.

This is why Google Cloud Firestore/Data store charges for rows returned, but the caveat is you can't do stuff like aggregations as the cost just doesn't work out

Re: PlanetScale increases plans to include billions of reads

#59

If PlanetScale just offered to reimburse any costs above the 99th percentile of normal operations it would be a great success. If their business model is dependent on people getting screwed by costs above the 99th percentile then they shouldn't be in business.

I was going to say I agree but I dont see how that would work. How do you define normal operation?
Post reply on HN