Comment by truetraveller | Hacker News Reader

Comment by truetraveller | Hacker News Reader

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 log? Will I be charged for these operations (can result in million+ writes)?

-What about small consecutive writes that fit in a single 16kb page, do I get charged a single write "unit"? RDS actually combines this into a single op (see IOPS with RDS).

-What about cached reads, do I get charged for that?

-What about computationally expensive queries, that do not actually read/write that much?

Please answer these questions. Provide useful real-world pricing examples. This is standard stuff, and especially important if "transparent" pricing is a key feature.

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.

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.

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

> I don't know what more you could be looking for as to what "rows read" means than `innodb_rows_read`

On the contrary, this is completely unclear because the mysql manual doesn't even give a clear explanation at all!! it only says "The number of rows read from InnoDB tables." https://dev.mysql.com/doc/refman/8.0/en/server-status-variab...

Let's say my db has a primary and 3 replicas. I insert one row. Does planetscale count this as 1 row written? 4 rows written?

Let's say my rows are small and there are 200 per DB page. I do a single-row select by primary key. This reads the page (you physically can't read just one "row" at the i/o level). Is this 1 row read or 200?

My read query triggers an internal temp table. Is the number of rows read based on only on the real tables, or also add in "reads" from the temp table? What if the temp table spills over to disk for a filesort?

I alter a table with 100 million rows. Is this 100 million rows read + 100 million rows written? or 0? something else? while this is happening, do my ongoing writes to the table count double for the shadow table?

Does planetscale even know the answers to these questions or are they just going by innodb status variables? do they actually have any innodb developers on staff or are they externalizing 100% of their actual "database" development to Oracle? (despite their blog post using wording like "we continue to build the best database on the planet"??)

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.

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.

If there's no egress, Planet Scale would make for a pretty neat blob cache store (key -> blob queries) to front S3 for hot objects... 100b reads per month with S3 would cost $40K+ for just GET requests (discounting egress): https://archive.is/4HYH6

Maybe the FAQs will go into more detail.

They don't!

Reply on news.ycombinator.com