Live data from Hacker News

PlanetScale increases plans to include billions of reads

planetscale.com

21–30 of 71 posts

Re: PlanetScale increases plans to include billions of reads

#21

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.

One of the things about a $29/mo RDS instance, though, is that if you're doing full table scans over a million rows, it's going to grind to a crawl and immediately alert you (not explicitly, but via the performance hit) that you're doing something wrong with indexing. Effectively, it's a hard budget cap, and that's super useful for budget-conscious organizations and individuals.

Does PlanetScale have functionality to provide budget alerts? Does it have the ability to speed-throttle calls that would require a budget increase to do effectively without further optimization, which effectively that CPU-capped RDS instance does de facto?

In other words, can I tell PlanetScale to cap my usage and throttle query speed if I exceed row scan limits, rather than blocking me entirely or charging my credit card more? If it doesn't yet have those capabilities, then I think it's fair to say it can easily be worse than an idle RDS host sitting around.

Re: PlanetScale increases plans to include billions of reads

#22

The pricing page/docs leaves so many questions unanswered: -What's the cost of egress? -What is a read/write exactly? It is a DB "page" read/write? I know there's a section on this, but it doesn't explain details. -If it's a page read/write, what is the size of the page? 16kb? -If it's a real row read/write, what is the maximum size? Can I write a 100mb row for the same price? -What about indexes, or merging the WAL…

You come off as quite demanding and expectant for apparently not having read their pricing page or billing docs, which specify very clearly that they're talking about row reads/writes.

They even go into examples with using `EXPLAIN`, `EXPLAIN ANALYZE`, `innodb_rows_read`, etc to see row counts.

https://docs.planetscale.com/concepts/billing

Re: PlanetScale increases plans to include billions of reads

#23

The pricing page/docs leaves so many questions unanswered: -What's the cost of egress? -What is a read/write exactly? It is a DB "page" read/write? I know there's a section on this, but it doesn't explain details. -If it's a page read/write, what is the size of the page? 16kb? -If it's a real row read/write, what is the maximum size? Can I write a 100mb row for the same price? -What about indexes, or merging the WAL…

Maybe the FAQs will go into more detail.

Re: PlanetScale increases plans to include billions of reads

#24
Look 200x more of something is 200x more, and 200x more for the same amount is a huge win for a service's users.

In the DB space though pricing per row or iop or this or that is tough. We're heavy users of BigQuery and the pricing per bytes consumed is tough, too, as you can't always rely on the estimator. But then if you go the fully pre-paid route like with something like Redshift you have high upfront fixed costs for an always on DB (that changed a bit with Redshift serverless -- currently in preview -- https://aws.amazon.com/redshift/redshift-serverless/) but I mean it's the same with BQ in that sense: don't run a query don't get charged except for stored data.

The point I am trying to make is that pricing of a DB is hard. If I had to choose I think I rather like the straight forward per second billing of serverless.

Re: PlanetScale increases plans to include billions of reads

#25
We wrote a blog post comparing RDS vs PlanetScale from a pricing perspective back in January...kudos to PlanetScale on responding to feedback on that so quickly. HN discussion here: https://news.ycombinator.com/item?id=29910812

We'll get the blog post updated but conceptually it seems like the "tipping point" of using PlanetScale vs RDS just got a lot easier at least from a read perspective - analysis is here: https://www.vantage.sh/blog/2022-01-12-rds-vs-planetscale-pr...

Re: PlanetScale increases plans to include billions of reads

#26
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.

Re: PlanetScale increases plans to include billions of reads

#28

The pricing page/docs leaves so many questions unanswered: -What's the cost of egress? -What is a read/write exactly? It is a DB "page" read/write? I know there's a section on this, but it doesn't explain details. -If it's a page read/write, what is the size of the page? 16kb? -If it's a real row read/write, what is the maximum size? Can I write a 100mb row for the same price? -What about indexes, or merging the WAL…

You come off as quite demanding and expectant for apparently not having read their pricing page or billing docs, which specify very clearly that they're talking about row reads/writes. They even go into examples with using `EXPLAIN`, `EXPLAIN ANALYZE`, `innodb_rows_read`, etc to see row counts. https://docs.planetscale.com/concepts/billing

Disagree, GP's expectations are perfectly reasonable

Their pricing page starts out by saying "Transparent pricing you can understand"! I shouldn't have to read a several thousand word FAQ, and then still come away wondering if cached pages still count as rows read

Cached page reads are free on Aurora, this makes a huge difference in pricing if it isn't the case on planetscale

Re: PlanetScale increases plans to include billions of reads

#29

The pricing page/docs leaves so many questions unanswered: -What's the cost of egress? -What is a read/write exactly? It is a DB "page" read/write? I know there's a section on this, but it doesn't explain details. -If it's a page read/write, what is the size of the page? 16kb? -If it's a real row read/write, what is the maximum size? Can I write a 100mb row for the same price? -What about indexes, or merging the WAL…

You come off as quite demanding and expectant for apparently not having read their pricing page or billing docs, which specify very clearly that they're talking about row reads/writes. They even go into examples with using `EXPLAIN`, `EXPLAIN ANALYZE`, `innodb_rows_read`, etc to see row counts. https://docs.planetscale.com/concepts/billing

I'm not demanding. If "transparent" pricing is a key feature, then please at least provide detailed billing info/examples. From the billing page you linked, still have many questions: If I have a row that's 100mb, is that counted as one read? What about index creation, is that counted? Or, merging the WAL log with the base, is that free? And what is a read "unit"? is this different than a "row read".

Re: PlanetScale increases plans to include billions of reads

#30

The pricing page/docs leaves so many questions unanswered: -What's the cost of egress? -What is a read/write exactly? It is a DB "page" read/write? I know there's a section on this, but it doesn't explain details. -If it's a page read/write, what is the size of the page? 16kb? -If it's a real row read/write, what is the maximum size? Can I write a 100mb row for the same price? -What about indexes, or merging the WAL…

Maybe the FAQs will go into more detail.

They don't!
Post reply on HN