41–50 of 71 posts
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-...
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.
Earlier quoted context omitted.
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 r…
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"??)
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-...
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.
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.
DynamoDB is the same, it charges you for the number of reads/writes you do, so if you're doing full table scans on massive databases, you're going to have a bad time.
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.
DynamoDB is the same, it charges you for the number of reads/writes you do, so if you're doing full table scans on massive databases, you're going to have a bad time.
I'm all for the aws hate when it's deserved, but if you get screwed by it on billing, you didn't read.
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…
If that's true, that will be similar to firestore when using limits and offsets. I really hate asymmetric pricing like this that forces developers to think in non standard way to reduce expenses. There is enough complexity as is in software development without more gotchas in billing.
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.
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.
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.
Hopefully you are not running a company nor anything that involves risk taking.