Just curious, how are indexes priced?
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?
PlanetScale increases plans to include billions of reads
61–70 of 71 posts
Re: PlanetScale increases plans to include billions of reads
#62Worth 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.
My big problem with SQL is that I want to do the query planning. Sure, the database can often do a better job -- but I want to be able to guarantee upper bounds on things, damn it! I've seen so many weird edge-case performance problems that boiled down to poor query plans. Things will be fast most of the time and then, suddenly, the database will look at its stats and decide to do a full table scan, and then everything goes straight to hell and stays there for too many milliseconds.
If I ever cross paths with a database, I'll spit on its shadow.
Re: PlanetScale increases plans to include billions of reads
#63This is similar to the problem we face, where you're charging based on usage of something people don't usually count. For us, that's GraphQL requests. 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 c…
It’s because it makes zero sense for me to care about how many requests I send when I have my own server.
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).
Re: PlanetScale increases plans to include billions of reads
#64I'm not really sure why a pricing change is HN-worthy, but I guess here I am biting: > 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?
One of the most common complain was the read [1], and now they have upped the bundled limit and cost thereafter as $1 per billion reads. [1] https://news.ycombinator.com/item?id=29132572
Yeah, but they didn’t actually adress the problem they stated customers had in their own blog post.
It feels like they’re just kicking the can down the road by increasing their numbers.
Re: PlanetScale increases plans to include billions of reads
#65The 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…
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
Re: PlanetScale increases plans to include billions of reads
#66Look 200x more of something is 200x more, and 200x more for the same amount is a huge win for a service's users. 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…
The answer really is do both kinds of pricing, like Cloudflare does with Workers.
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...
Re: PlanetScale increases plans to include billions of reads
#67Earlier quoted context omitted.
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 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 b…
Strongly agree. There is a huge amount of value in what RDS provides (over DIY EC2).
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.
Re: PlanetScale increases plans to include billions of reads
#68Can 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…
{supabase ceo}
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).
Re: PlanetScale increases plans to include billions of reads
#69Earlier 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.
This limitation prohibits the use of joins until a session parameter like 'set max_logical_reads to xxx' is available.
Re: PlanetScale increases plans to include billions of reads
#70Worth 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.
One difference with DynamoDB is that there's no query planner, so you can have a pretty good sense of how many items you'll hit and how big that read is.