5 ms·

PlanetScale Scaler Pro

131 points by JackWritesCode 3y ago

darkhorse13 3y ago
The only thing stopping me from using this is the lack of foreign keys. Is that ever coming?
- samlambert 3y ago
  Yes, it's on its way.
- deleted 3y ago
  [deleted]
tiagod 3y ago
Would be nice for the first table to have the pricing, and a comparison with the old plan as well...
- tbarn 3y ago
  We are getting the chart updated with the pricing now. Thanks for pointing that out.
- AYBABTME 3y ago
  The pricing page shows the old plan starts at 29$/month for row-based pricing, and the new one at 39$/month for resource-based pricing: https://planetscale.com/pricing https://planetscale.com/pricing
ksec 3y ago
Tl;dr: This new plan basically fix the number one complain about PlanetScale and offers Unlimited row reads and writes.
- steventey 3y ago
  wow that's incredible!!
- kubectl_h 3y ago
  Next up is the new number one complain, lack of PITR. When that's ready I can finally realistically propose moving to PlanetScale to my team. I cannot wait for the day.
  - samlambert 3y ago
    I'd love to learn about your requirements. Can we chat? s@planetscale.com
JoshGlazebrook 3y ago
Excited to see this finally rolled out. Now just waiting on the foreign key constraint support.
- joshstrange 3y ago
  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/ https://vitess.io/blog/2021-06-15-online-ddl-why-no-fk/
  - samlambert 3y ago
    It's going to happen.
    - joshstrange 3y ago
      Very cool! I didn't know that was on the roadmap.
      - osser 3y ago
        It's on the official Vitess roadmap, though you do have to search on this page for it https://vitess.io/docs/resources/roadmap/ https://vitess.io/docs/resources/roadmap/
  - tbarn 3y ago
    We are working on foreign key constraint support right now. :)
- samlambert 3y ago
  It's on its way!
  - belmont_sup 3y ago
    This is great news. I strolled around https://github.com/vitessio/vitess/issues/12967 https://github.com/vitessio/vitess/issues/12967. Are there any public discussions of more trade-offs vitess has to make to enable fks?
mebcitto 3y ago
I 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.
- CtrlAltDelete51 3y ago
  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.”
  - rrdharan 3y ago
    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.
joshstrange 3y ago
I 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.
- hu3 3y ago
  I'm interested in using PlanetScale. Would you happen to know the magnitude of how many simultaneous connections could $348/yr buy me in PlanetScale? One of my clients hovers around 50 simultaneous connections to their main MySQL server on a normal day, but they have bursts of 3k simultaneous connections for an entire day, twice per year. Their workload is about 5% writting (INSERTs, UPDATEs), 95% reading (SELECTS).
  - gsanderson 3y ago
    The blog post shows both the Scaler and Scaler Pro plan supporting up to 10,000 concurrent connections: https://planetscale.com/blog/announcing-scaler-pro#scaler-pro-pricing https://planetscale.com/blog/announcing-scaler-pro#scaler-pr...
  - purelogiq 3y ago
kkzz99 3y ago
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?
- wirelesspotat 3y ago
  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 [0] https://planetscale.com/legal/data-processing-addendum https://planetscale.com/legal/data-processing-addendum
colesantiago 3y ago
It's great MySQL is still getting some love. I have no complaints with it.
taw1516 3y ago
love PlanetScale product. Do you recommend any similar offering for PostgresSQL?
- slig 3y ago
  https://neon.tech/ https://neon.tech/
  - mdasen 3y ago
    Neon is a great suggestion. I'm just writing to add a bit more color. Neon is a bit different from PlanetScale. With PlanetScale, they're running Vitess under the covers. Vitess is a proxy that sits between you and the MySQL database. It means they can do fancy things like rewrite the queries on the way to the database or route them differently. For example, a "SELECT" query could be sent to a replica instate of the primary. Likewise, if you've sharded/partitioned your data by customer_id, Vitess could see the query says "WHERE customer_id = 5" and send it to the correct server. This proxy also means that Vitess can seamlessly manage some things for you like failing over to a new database or bringing online a new replica. Neon is a decoupling of storage from the database processing. While Vitess still has MySQL storing the data, Neon changes the storage so that it can separate data processing and data storage. This is somewhat like Amazon's Aurora. If you're interested in other PostgreSQL compatible options, CockroachDB is PostgreSQL compatible, but is more of a fully distributed database from the ground up rather than new layers like Neon or PlanetScale.
- tristan957 3y ago
  I work at Neon like the other person mentioned, but I believe Supabase is Postgres compatible, though I haven't looked into them much.
new_user_final 3y ago
What 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?
Illniyar 3y ago
Am I missing something in the pricing or is the Storage costs very unappealing. For anything with a usage skewed towards high ratio of storage to usage, the costs aren't competitive. 2.5$ per GB in "Scalar" and 1.5$ per GB in "Scalar PRO" compared to 0.11$ RDS for General purpose (or 0.125$ for provisioned + the IOPS you use, double that for multi-az), Supabase at 0.125$, Firebase at 0.1725$,DynamoDB at 0.25$, MongoDB Atlas serverless at 0.25$, cockroachDB serverless at 0.5$ per GB, FaunaDB at 1$ per GB. (Neon says it's 0.000164 per GiB, but somethings seems off, it's not at the same scale, so I'm guessing there's a catch here)
- mebcitto 3y ago
  Neon price is listed as per hour, instead of per month like the others :) While you're not necessarily missing something, it's worth pointing out that usually storage costs don't dominate the bill, the compute costs are usually higher. But with the PlanetScale storage price being more then 10x the price of the other, it's definitely something to keep in mind, and it can dominate the bill.
- re-thc 3y ago
  > Am I missing something in the pricing or is the Storage costs very unappealing Yes, there's no comparison on the IOPs or anything else and what counts as storage. They all count slightly differently and so unless you account for it all it's a bit moot. AWS alone has different tiers of storage from HDD to NVME ssd. The pricing varies greatly. RDS will literally count anything including temporary files as usage of storage. Planetscale claims not to.

darkhorse13 3y ago

The only thing stopping me from using this is the lack of foreign keys. Is that ever coming?

samlambert 3y ago
Yes, it's on its way.
deleted 3y ago
[deleted]

tiagod 3y ago

Would be nice for the first table to have the pricing, and a comparison with the old plan as well...

tbarn 3y ago
We are getting the chart updated with the pricing now. Thanks for pointing that out.
AYBABTME 3y ago
The pricing page shows the old plan starts at 29$/month for row-based pricing, and the new one at 39$/month for resource-based pricing: https://planetscale.com/pricing https://planetscale.com/pricing

ksec 3y ago

Tl;dr: This new plan basically fix the number one complain about PlanetScale and offers Unlimited row reads and writes.

steventey 3y ago
wow that's incredible!!
kubectl_h 3y ago
Next up is the new number one complain, lack of PITR. When that's ready I can finally realistically propose moving to PlanetScale to my team. I cannot wait for the day.
- samlambert 3y ago
  I'd love to learn about your requirements. Can we chat? s@planetscale.com

JoshGlazebrook 3y ago

Excited to see this finally rolled out. Now just waiting on the foreign key constraint support.

joshstrange 3y ago
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/ https://vitess.io/blog/2021-06-15-online-ddl-why-no-fk/
- samlambert 3y ago
  It's going to happen.
  - joshstrange 3y ago
    Very cool! I didn't know that was on the roadmap.
    - osser 3y ago
      It's on the official Vitess roadmap, though you do have to search on this page for it https://vitess.io/docs/resources/roadmap/ https://vitess.io/docs/resources/roadmap/
- tbarn 3y ago
  We are working on foreign key constraint support right now. :)
samlambert 3y ago
It's on its way!
- belmont_sup 3y ago
  This is great news. I strolled around https://github.com/vitessio/vitess/issues/12967 https://github.com/vitessio/vitess/issues/12967. Are there any public discussions of more trade-offs vitess has to make to enable fks?

mebcitto 3y ago

I 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.

CtrlAltDelete51 3y ago
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.”
- rrdharan 3y ago
  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.

joshstrange 3y ago

I 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.

hu3 3y ago
I'm interested in using PlanetScale. Would you happen to know the magnitude of how many simultaneous connections could $348/yr buy me in PlanetScale? One of my clients hovers around 50 simultaneous connections to their main MySQL server on a normal day, but they have bursts of 3k simultaneous connections for an entire day, twice per year. Their workload is about 5% writting (INSERTs, UPDATEs), 95% reading (SELECTS).
- gsanderson 3y ago
  The blog post shows both the Scaler and Scaler Pro plan supporting up to 10,000 concurrent connections: https://planetscale.com/blog/announcing-scaler-pro#scaler-pro-pricing https://planetscale.com/blog/announcing-scaler-pro#scaler-pr...
- purelogiq 3y ago

kkzz99 3y ago

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?

wirelesspotat 3y ago
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 [0] https://planetscale.com/legal/data-processing-addendum https://planetscale.com/legal/data-processing-addendum

colesantiago 3y ago

It's great MySQL is still getting some love. I have no complaints with it.

taw1516 3y ago

love PlanetScale product. Do you recommend any similar offering for PostgresSQL?

slig 3y ago
https://neon.tech/ https://neon.tech/
- mdasen 3y ago
  Neon is a great suggestion. I'm just writing to add a bit more color. Neon is a bit different from PlanetScale. With PlanetScale, they're running Vitess under the covers. Vitess is a proxy that sits between you and the MySQL database. It means they can do fancy things like rewrite the queries on the way to the database or route them differently. For example, a "SELECT" query could be sent to a replica instate of the primary. Likewise, if you've sharded/partitioned your data by customer_id, Vitess could see the query says "WHERE customer_id = 5" and send it to the correct server. This proxy also means that Vitess can seamlessly manage some things for you like failing over to a new database or bringing online a new replica. Neon is a decoupling of storage from the database processing. While Vitess still has MySQL storing the data, Neon changes the storage so that it can separate data processing and data storage. This is somewhat like Amazon's Aurora. If you're interested in other PostgreSQL compatible options, CockroachDB is PostgreSQL compatible, but is more of a fully distributed database from the ground up rather than new layers like Neon or PlanetScale.
tristan957 3y ago
I work at Neon like the other person mentioned, but I believe Supabase is Postgres compatible, though I haven't looked into them much.

new_user_final 3y ago

What 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?

Illniyar 3y ago

Am I missing something in the pricing or is the Storage costs very unappealing. For anything with a usage skewed towards high ratio of storage to usage, the costs aren't competitive. 2.5$ per GB in "Scalar" and 1.5$ per GB in "Scalar PRO" compared to 0.11$ RDS for General purpose (or 0.125$ for provisioned + the IOPS you use, double that for multi-az), Supabase at 0.125$, Firebase at 0.1725$,DynamoDB at 0.25$, MongoDB Atlas serverless at 0.25$, cockroachDB serverless at 0.5$ per GB, FaunaDB at 1$ per GB. (Neon says it's 0.000164 per GiB, but somethings seems off, it's not at the same scale, so I'm guessing there's a catch here)

mebcitto 3y ago
Neon price is listed as per hour, instead of per month like the others :) While you're not necessarily missing something, it's worth pointing out that usually storage costs don't dominate the bill, the compute costs are usually higher. But with the PlanetScale storage price being more then 10x the price of the other, it's definitely something to keep in mind, and it can dominate the bill.
re-thc 3y ago
> Am I missing something in the pricing or is the Storage costs very unappealing Yes, there's no comparison on the IOPs or anything else and what counts as storage. They all count slightly differently and so unless you account for it all it's a bit moot. AWS alone has different tiers of storage from HDD to NVME ssd. The pricing varies greatly. RDS will literally count anything including temporary files as usage of storage. Planetscale claims not to.