Excited to see this finally rolled out. Now just waiting on the foreign key constraint support.
EDIT: Ignore this comment, I was mistaken
I don't believe that will ever happen due to the underlying Vitess tech [0] that PlanetScale uses
PlanetScale Scaler Pro
11–20 of 44 posts
Re: PlanetScale Scaler Pro
#12Excited to see this finally rolled out. Now just waiting on the foreign key constraint support.
It's on its way!
Re: PlanetScale Scaler Pro
#13Excited to see this finally rolled out. Now just waiting on the foreign key constraint support.
EDIT: Ignore this comment, I was mistaken I don't believe that will ever happen due to the underlying Vitess tech [0] that PlanetScale uses [0] https://vitess.io/blog/2021-06-15-online-ddl-why-no-fk/
It's going to happen.
Re: PlanetScale Scaler Pro
#14Excited to see this finally rolled out. Now just waiting on the foreign key constraint support.
EDIT: Ignore this comment, I was mistaken I don't believe that will ever happen due to the underlying Vitess tech [0] that PlanetScale uses [0] https://vitess.io/blog/2021-06-15-online-ddl-why-no-fk/
We are working on foreign key constraint support right now. :)
Re: PlanetScale Scaler Pro
#15I 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 type they chose, but indeed it seems cheaper.~~ But that doesn't take into account reserved instances, which can lower the price on the RDS side.
Edit: Looking again, I think the instance used for comparison is `db.r6gd.xlarge` from the Multi AZ-deployments (two standbys) list. That is $1.445/h, so $1054 / month. The difference could be for storage and I/O.
However, the PS Scaler Pro is $1.5 / GB, which is quite a lot. General purpose storage in AWS is only $0.115. The comparison table uses 10 GB only, but if the DB size is 1 TB, then RDS would be a lot cheaper?
Please correct me if I got something wrong, I'm sure there's stuff I'm missing.
Re: PlanetScale Scaler Pro
#16I love PlanetScale and if I had one request it would be a plan between Hobby and Scalar (or even a way to combine multiple DBs in 1 plan, and no 2 prod branches won't cut it).
I have 2 paid Scalar DBs on PlanetScale and I have no intention of moving elsewhere but it does kill me that they both sit almost unused ~10 months out of the year (I have bursty traffic and only during the events, in-person events, that the software is built for). At ~$348/yr per DB it's still a steal compared to managing it all myself but I look at my usage (even during my "busy" months) and I barely make a dent in the usage tier I'm on. In fact I think you could total up my total usage for the lifetime of my account (both DBs) and they wouldn't total up to 1 month of the usage tier.
Again, I'm not complaining and the cost is manageable but I did create and sell some new software in the last year that I built on DynamoDB (in part to learn, in part due to costs). My software that uses PS is single-tenant so I need 1 per client which is on me, if I was able to rewrite it to be multi-tenant then I'd only have to pay $348 total a year instead of per-client.
All in all I have had nothing but good experiences with PlanetScale from the product itself to the support staff. I love the migrations and the rollback support, it feels natural when you start using it and dealing with migrations in other DBs feels like a huge pain once you've done it in PlanetScale.
Re: PlanetScale Scaler Pro
#17Earlier quoted context omitted.
EDIT: Ignore this comment, I was mistaken I don't believe that will ever happen due to the underlying Vitess tech [0] that PlanetScale uses [0] https://vitess.io/blog/2021-06-15-online-ddl-why-no-fk/
It's going to happen.
Very cool! I didn't know that was on the roadmap.
Re: PlanetScale Scaler Pro
#18I 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 some glaring issues I don’t want to deal with:
- no native way to export backups and avoid vendor lock in (or pay for the row reads to generate regular backups)
- contradictory cost model. Their pricing page reads “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.” while their docs state “Rows read is a measure of the work that the database engine does, not a measure of the number of rows returned. Every row read from a table during execution adds to the rows read count, regardless of how many rows are returned.”
Re: PlanetScale Scaler Pro
#19The only thing stopping me from using this is the lack of foreign keys. Is that ever coming?
Yes, it's on its way.
Re: PlanetScale Scaler Pro
#20Excited to see this finally rolled out. Now just waiting on the foreign key constraint support.
This is the only real thing stopping me from trying PlanetScale as well, glad to see in the comments that it's coming.