PlanetScale increases plans to include billions of reads(planetscale.com) |
PlanetScale increases plans to include billions of reads(planetscale.com) |
https://docs.planetscale.com/concepts/billing#understanding-...
If I ever cross paths with a database, I'll spit on its shadow.
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.
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...
I'm guessing the "difficult to understand and hard for you to predict" is around how the read pricing is based on how many rows MySQL needs to read in order to serve your query. That's going to depend on how the query optimizer executes your query (and what indexes you've made and such).
It does make me wonder if I'm allowed to create as many indexes as I want without incurring additional "writes". Their billing page makes it seem like indexes don't count: https://docs.planetscale.com/concepts/billing. In fact, their storage language makes it seem like indexes aren't charged for storage: "Data saved in the form of tables, columns, rows, and their corresponding relationships." I'm guessing that's just an oversight and the thinking is that "tables" covers indexes, but wouldn't "tables" also cover "columns, rows, and their corresponding relationships?" Given the expensive storage at $2.50/GB, how big things are seems to matter. Cockroach charges $1/GB (60% less), Google charges $0.34/GB for Cloud SQL HA storage, and $0.33/GB for Cloud Spanner storage (and 2-3x that if you're going multi-region). $2.50 is a big premium.
It still seems like there's an incentive to over-index rather than doing small filtering in-memory, though the incentive is now 99% smaller. Likewise, there seems to be no charge for doing something that requires sorting - or maybe they consider the sort to be a re-read of all the results? Looking over MySQL's explain analyze results, it looks like there shouldn't be a cost for reading through the index.
Sorry for the random thoughts. PlanetScale is a great project to offer a serverless MySQL on top of Vitess. I wish Vitess existed for PostgreSQL (we use Postgres' GIN indexes with JSON so it's not easy to move to MySQL).
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...
The limit is basically 31 x 24 x 3600 x [req per second server can handle]
Even at a relatively low rate of 10rps that is 26M requests per month.
Now putting a demo environment at 2 rps per second for a whole month is pretty generous, but until I took the time to calculate it, it sounded like a pretty bad value proposition to me (even though I probably make less than 1000 requests per day).
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/etc.
CockroachDB Serverless includes 250M "request units" (request units include reads and writes and individual requests can costs multiple units depending on size). They charge an extra $1 per month per 10M "request units," so $75 to get to 1B reads at least.
Am I missing something? What's the catch?
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.
> We’ve also heard your feedback about how our pricing is difficult to understand and hard for you to predict.
> Starting March 1st we’ll be offering our customers up to 200x more reads across all pricing plans.
Just giving more reads doesn't seem like it's actually simplifying pricing or making it more predictable?
And since as you mentioned from the post its a popular complaint so I figured others might be interested in this change as well.
It feels like they’re just kicking the can down the road by increasing their numbers.
-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.
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.
Workers Bundled is priced for upto 50ms of CPU time and unlimited egress. Workers Unbound is priced per-ms of 8xCPU or 1xIO time, which ever is higher.
I mean, pricing is hard, but at least read through these if nothing else: https://html.duckduckgo.com/html/search?q=inurl%3Ahbr.org%20...
This is true, we do offer some extra functionality - but also I want to point out that the database we provide is "just" Postgres. You can use it as a standalone database without any of the other functionality. We give "postgres level access", so you can use it just like RDS or any other DBaaS
for example, we commonly see Prisma developers using our databases (because we also provide pgbouncer, a connection pooler).
I assume you’ll pay $2.50/GB for storage, but if I update a row that touches 5 indexes is this 1 write or 6?
I'm keen for Spanner/CockroachDB!
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!
They even go into examples with using `EXPLAIN`, `EXPLAIN ANALYZE`, `innodb_rows_read`, etc to see row counts.
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'm all for the aws hate when it's deserved, but if you get screwed by it on billing, you didn't 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.
>"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.
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.
Fellow HN user quinnypig described it succinctly:
RDS is a huge win not because of anything intrinsic to what the platform actually is, but because we collectively suck at setting up and managing replication, backups, etc.
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.
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 .
Hopefully you are not running a company nor anything that involves risk taking.
> 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.
> 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`.
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"??)