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.
PlanetScale increases plans to include billions of reads
51–60 of 71 posts
Re: PlanetScale increases plans to include billions of reads
#52Re: PlanetScale increases plans to include billions of reads
#53Earlier 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.
Re: PlanetScale increases plans to include billions of reads
#54Worth 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.
Re: PlanetScale increases plans to include billions of reads
#55This 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…
Re: PlanetScale increases plans to include billions of reads
#56Earlier 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.
Re: PlanetScale increases plans to include billions of reads
#57I'm keen for Spanner/CockroachDB!
Re: PlanetScale increases plans to include billions of reads
#58Worth 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.
Re: PlanetScale increases plans to include billions of reads
#59If 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.