The last time I recommended to use planetscale at my company the only factor that stopped us using them was GDPR/DSGVO. Any news about a europe friendly version?
PlanetScale Scaler Pro
21–30 of 44 posts
Re: PlanetScale Scaler Pro
#22The only thing stopping me from using this is the lack of foreign keys. Is that ever coming?
[deleted]
Re: PlanetScale Scaler Pro
#23I kind of have a thing for DBaaS pricing, and that table with the comparison with RDS looked suspicious to me because it doesn't specify the exact instance type used on the AWS side. ~~I think it should be `db.r6g.xlarge` because it has 4 vCPUs and 32 GB RAM. That is $0.43/h, so $0.43 * 730 = $313 / month. They have one primary and 2 replicas, so 313 x 3 = $940. It doesn't quite fit, so maybe that's not the instance…
> PS Scaler Pro is $1.5 / GB, which is quite a lot. General purpose storage in AWS is only $0.115.
GP storage is pretty slow (relatively). I hope PS isn't giving us that out of the box and does provision more IOPs etc.
AWS bills for absolutely everything as PS mentioned in the article. This can include temporary files and what not that can take up a large chunk of your storage.
> because it doesn't specify the exact instance type used on the AWS side
That in a way is problematic because CPU generations matter and even if PS is using the "best" currently, how do we know if they'd keep up? Prices could swing the other way quite easily.
Re: PlanetScale Scaler Pro
#24It's great MySQL is still getting some love. I have no complaints with it.
Re: PlanetScale Scaler Pro
#25love PlanetScale product. Do you recommend any similar offering for PostgresSQL?
Re: PlanetScale Scaler Pro
#26What is the expected performance? If I have a very simple table with 100k records, what will be the expected read/write/update tps? I know it depends on many things, but still any guesses?
Re: PlanetScale Scaler Pro
#27I kind of have a thing for DBaaS pricing, and that table with the comparison with RDS looked suspicious to me because it doesn't specify the exact instance type used on the AWS side. ~~I think it should be `db.r6g.xlarge` because it has 4 vCPUs and 32 GB RAM. That is $0.43/h, so $0.43 * 730 = $313 / month. They have one primary and 2 replicas, so 313 x 3 = $940. It doesn't quite fit, so maybe that's not the instance…
If they are running on AWS (which it looks like they are), they aren’t going to be able to undercut AWS. For a retail user who doesn’t want to commit to RIs or have enough volume for an EDP, sure PS can be cheaper. The value I found is being able to do multi-region read replicas with no compute overhead for lower traffic geos. I like the idea of PS and have toyed around with the idea of migrating to it but there are…
That’s not contradictory?
It’s very common for scale-out architectures to read more data than is ultimately returned, because the former is pulled from individual shards and then some centralized filtering / post processing is applied in some API middleware layer.
Trying to fix that by pushing down more of the query/execution is sometimes but not always feasible or practical.
Re: PlanetScale Scaler Pro
#28Earlier quoted context omitted.
It's going to happen.
Very cool! I didn't know that was on the roadmap.
It's on the official Vitess roadmap, though you do have to search on this page for it https://vitess.io/docs/resources/roadmap/
Re: PlanetScale Scaler Pro
#29The last time I recommended to use planetscale at my company the only factor that stopped us using them was GDPR/DSGVO. Any news about a europe friendly version?
Do you know specifics they're missing?
At a glance, their Data Processing Addendum[0] seems to address GDPR, along with country-specific regulations like Swiss DPA and UK GDPR
Re: PlanetScale Scaler Pro
#30love PlanetScale product. Do you recommend any similar offering for PostgresSQL?