[HN Gopher] PlanetScale Scaler Pro
___________________________________________________________________
PlanetScale Scaler Pro
Author : JackWritesCode
Score : 113 points
Date : 2023-07-06 15:23 UTC (7 hours ago)
(HTM) web link (planetscale.com)
(TXT) w3m dump (planetscale.com)
| darkhorse13 wrote:
| The only thing stopping me from using this is the lack of foreign
| keys. Is that ever coming?
| samlambert wrote:
| Yes, it's on its way.
| [deleted]
| new_user_final wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mebcitto wrote:
| 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 wrote:
| 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 wrote:
| 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.
| semiquaver wrote:
| (responding to GP) "Full table scans are expensive" is a
| better way to reframe the pricing model (at least before
| this pricing change). The distinction is between rows
| _examined_ vs rows _returned to a db client_. Even the
| latter is a tricky concept with vitess since it's a
| routing/sharding system that sits on top of vanilla MySQL
| instances.
| re-thc wrote:
| > 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.
| taw1516 wrote:
| love PlanetScale product. Do you recommend any similar offering
| for PostgresSQL?
| slig wrote:
| https://neon.tech/
| mdasen wrote:
| 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.
| tiagod wrote:
| Would be nice for the first table to have the pricing, and a
| comparison with the old plan as well...
| AYBABTME wrote:
| 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
| tbarn wrote:
| We are getting the chart updated with the pricing now. Thanks
| for pointing that out.
| JoshGlazebrook wrote:
| Excited to see this finally rolled out. Now just waiting on the
| foreign key constraint support.
| joshstrange wrote:
| 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/
| samlambert wrote:
| It's going to happen.
| joshstrange wrote:
| Very cool! I didn't know that was on the roadmap.
| osser wrote:
| It's on the official Vitess roadmap, though you do have
| to search on this page for it
| https://vitess.io/docs/resources/roadmap/
| tbarn wrote:
| We are working on foreign key constraint support right now.
| :)
| samlambert wrote:
| It's on its way!
| badrequest wrote:
| This is the only real thing stopping me from trying PlanetScale
| as well, glad to see in the comments that it's coming.
| colesantiago wrote:
| It's great MySQL is still getting some love. I have no complaints
| with it.
| joshstrange wrote:
| 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 wrote:
| 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).
| purelogiq wrote:
| Planetscale advertises up to 10,000 concurrent connections on
| their $29/mo Scalar plan (https://planetscale.com/pricing -
| click on "Compare all plan options and benefits"). Being
| based on Vitess as well, I believe that number.
| gsanderson wrote:
| 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-
| pr...
| tbarn wrote:
| This number of connections on any of the paid plans should be
| no issue.
| no_wizard wrote:
| you might find Supabase[0] is closer to what you need. I'd
| recommend giving them a look, that is, if MySQL compat isn't a
| requirement of course, since Supabase is all PostgresSQL.
|
| disclosure: not a employee or investor in Supabase, but I sure
| am a fan.
|
| [0]: https://supabase.com/
| kkzz99 wrote:
| 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 wrote:
| 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
| ksec wrote:
| Tl;dr: This new plan basically fix the number one complain about
| PlanetScale and offers Unlimited row reads and writes.
| steventey wrote:
| wow that's incredible!!
| kubectl_h wrote:
| 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 wrote:
| I'd love to learn about your requirements. Can we chat?
| s@planetscale.com
___________________________________________________________________
(page generated 2023-07-06 23:01 UTC)