Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PlanetScale increases plans to include billions of reads

planetscale.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: PlanetScale increases plans to include billions of reads

#31

Post by LewisJEllis »

throwusawayus wrote: post #28
LewisJEllis wrote: post #22

Earlier quoted context omitted.

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

I agree with you that there are some simple questions left unanswered, but "is it row reads?" is not one of them.

Re: PlanetScale increases plans to include billions of reads

#32

Post by throwusawayus »

LewisJEllis wrote: post #31
throwusawayus wrote: post #28

Earlier quoted context omitted.

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

I agree with you that there are some simple questions left unanswered, but "is it row reads?" is not one of them.

The linked blog post literally just says "reads". The word "rows" does not appear in the blog post! You have to click through, yes it's clear once you do, but i'd say it's a valid complaint about the blog post

Re: PlanetScale increases plans to include billions of reads

#33

Post by mirntyfirty »

fabian2k wrote: post #26
felixr wrote: 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.

True, even with tuned indices table scans are pretty frequent and perhaps one would want a slower but cheaper query. It’d be quite stressful to have to worry about query plans executed because they can vary quite a bit across very similar queries and be nudged towards more expensive queries by development teams.

Re: PlanetScale increases plans to include billions of reads

#34

Post by LewisJEllis »

throwusawayus wrote: post #32
LewisJEllis wrote: post #31

Earlier quoted context omitted.

I agree with you that there are some simple questions left unanswered, but "is it row reads?" is not one of them.

The linked blog post literally just says "reads". The word "rows" does not appear in the blog post! You have to click through, yes it's clear once you do, but i'd say it's a valid complaint about the blog post

The comment by truetraveller is complaining about the pricing and docs, not the blog post:

> The pricing page/docs leaves so many questions unanswered:

The pricing page and docs make "rows" very clear. I was never referring to the blog post, nor was truetraveller.

Re: PlanetScale increases plans to include billions of reads

#35

Post by LewisJEllis »

truetraveller wrote: post #29
LewisJEllis wrote: post #22

Earlier quoted context omitted.

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".

Your comment used to read:

> C'mon guys, this is super basic.

which came off as demanding, until you edited it after my response to instead read "This is standard stuff".

It's bad form to make substantial edits an hour later after you've been replied to, especially if you then refute the reply based in part on that edit.

I agree with you that more examples would be helpful, and you have some good questions which are left unanswered, but "is it rows?" was answered very clearly by the pricing page and billing docs.

Re: PlanetScale increases plans to include billions of reads

#36

Post by fabian2k »

mirntyfirty wrote: post #33
fabian2k wrote: post #26

Earlier quoted context omitted.

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.

True, even with tuned indices table scans are pretty frequent and perhaps one would want a slower but cheaper query. It’d be quite stressful to have to worry about query plans executed because they can vary quite a bit across very similar queries and be nudged towards more expensive queries by development teams.

If your application allows somewhat flexible queries this might also create potential Denial of Money attacks, which I personally find scarier than plain old Denial of Service. I mean that's always a risk with this type of pricing, but the particulars of a relational database with a query planner makes this a lot more dangerous.

Re: PlanetScale increases plans to include billions of reads

#37

Post by truetraveller »

LewisJEllis wrote: post #35
truetraveller wrote: post #29

Earlier quoted context omitted.

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".

Your comment used to read: > C'mon guys, this is super basic. which came off as demanding, until you edited it after my response to instead read "This is standard stuff". It's bad form to make substantial edits an hour later after you've been replied to, especially if you then refute the reply based in part on that edit. I agree with you that more examples would be helpful, and you have some good questions which are…

I edited it because I didn't want to be mean, and I thought that might have been mean. My intention was not to be less "demanding". In fact, I added to more questions to my list with my edit. So, I became even more demanding!

>"is it rows?" was answered very clearly

In the world of DBs, "rows" is extremely vague. We need more info, which is the point of my post.

Re: PlanetScale increases plans to include billions of reads

#38

Post by truetraveller »

LewisJEllis wrote: post #34
throwusawayus wrote: post #32

Earlier quoted context omitted.

The linked blog post literally just says "reads". The word "rows" does not appear in the blog post! You have to click through, yes it's clear once you do, but i'd say it's a valid complaint about the blog post

The comment by truetraveller is complaining about the pricing and docs, not the blog post: > The pricing page/docs leaves so many questions unanswered: The pricing page and docs make "rows" very clear. I was never referring to the blog post, nor was truetraveller.

They do not make it clear.

Re: PlanetScale increases plans to include billions of reads

#39

Post by joshstrange »

bachmeier wrote: post #27

Can anyone comment on PlanetScale vs Supabase? I'm not their target, because I'm just a random individual that wants a free database for personal projects. I could try both but would be nice to hear about someone's experience.

From my understanding Supabase is more of "all-in-one backend" whereas PlanetScale is "just" a DB (MySQL vs the Postgres it looks like you get on Supabase). PlanetScale also has some pretty awesome tools for moving DB schema changes between environments (zero downtime) and I don't know what Supabase provides for something like this. If all you want is a DB then give PS a try, I'm loving it so far, if you want a full backend "no code/low code"-firebase-like thing then Supabase might be for you. Personally I don't like going "all in" on something as important as "my whole backend", I'm much happier just getting a DB from PS and then using AWS Lambda as my "backend".

Re: PlanetScale increases plans to include billions of reads

#40

Post by LewisJEllis »

truetraveller wrote: post #38
LewisJEllis wrote: post #34

Earlier quoted context omitted.

The comment by truetraveller is complaining about the pricing and docs, not the blog post: > The pricing page/docs leaves so many questions unanswered: The pricing page and docs make "rows" very clear. I was never referring to the blog post, nor was truetraveller.

They do not make it clear.

From the pricing page:

> How are rows read and rows written calculated? > Every time a query retrieves a row from the database, it is counted as a row read. Every time a row is written to the database, it is counted as a row written.

From the billing docs:

> our paid Scaler plan comes with 25 GB storage, 100 billion row reads, and 50 million row writes

> Every row read from a table during execution adds to the rows read count, regardless of how many rows are returned.

> You can test a query for approximate rows read using the EXPLAIN statement. Running EXPLAIN with your query will return information about the query execution plan.

> To see the exact rows read, you will need to run the query. You can use the EXPLAIN ANALYZE statement to do this. It will return the estimated information about how it will run the query, run the query, and then return the actual impact from running the query.

> Another useful way to check rows read is using innodb_rows_read. This server status variable will show you the number of rows read across all tables. You can run it before and after queries to calculate how many rows were read.

These bits are extremely specific, down to the storage engine level. I don't know what more you could be looking for as to what "rows read" means than `innodb_rows_read`.

Post reply on HN