11–20 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 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…
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 customers (the bill has increased for 2 customers because they have very unique workloads, we are providing them discounts to mitigate).
One thing to mention is that our storage includes replication of the data. We never want customers to worry about how many copies to keep to achieve HA so we do that for them and that is represented in this price.
We are continuing to optimize with the customer in mind and I am sure there will be further iterations. Stay tuned!
-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.
While certainly big companies have monitoring for this kind of thing set up, we learned that a majority of engineering teams have absolutely no clue how many GraphQL requests they get per month. Like, not even a ballpark. Hundreds of thousands? Millions? Billions? No clue, could be any of those.
Our free plan was originally 5M free requests per month, which is relatively generous — but people didn't know and thus we had almost no users on the free plan. We recently changed it to just be "free for solo developers working on side projects / indie hacking / etc. no matter how many requests".[0]
So far, the change's been well received! Curious to see Planetscale dealing with the same general kind of issue, just on a different layer.
[0]: https://graphcdn.io/blog/unlimited-free-requests-for-develop...
Database reads/writes are really hard (read: impossible) to predict unless you are already in production. Leading to thoughts like: "1 Billion reads!! I'll never use that much..." Once you cross the line, the overages kick in. That being said, this does appear to be absurdly cheap compared to competitors. Amazon Aurora appears to be sitting at around $200 a month for 1 billion reads, excluding writes/transfer/storage…
If you're doing a range scan query and your rows are reasonably-sized, you can conceivably get tens of rows to maybe even a few hundred rows per single I/O operation. Or even 0 I/O operations if the pages are already in memory in the buffer pool cache.
Planetscale prices based on rows.. And scanning a few FAQs I don't see anything about cached rows being free, but maybe i missed it.
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.
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.
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.
rds gives you automatic backups, automatic failover with DNS, easy upgrades, IAM authentication, an API for manipulating your database instances, and more.
As ceo it damages your company's credibility when you say it's just `apt-get install mysql-server`. Please do better.
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.
I'd roll my own again for many reasons, not least because AWS is ridiculously overpriced, but if you're first using EC2 and so already taking the costs of being on AWS I'd recommend people use RDS over rolling their own any day unless they're very familiar with what proper redundancy and backup strategies entails .