> If one only needs a database, it's probably not worth to go to AWS
I think PlanetScale is built for someone who isn't using raw machines to build an app or running a dev-ops org.
Something like Vercel+PlanetScale is more along the lines of tooling you're likely to use (or Heroku if you're dealing with existing code).
The egress costs are rarely an issue for API endpoints, unless you're serving assets out of the hosts.
There's a million intranet-like workflow apps which don't need the additional headache of maintaining an RDS (or the skills to secure IAM). Mostly state machines with click-next-to-continue - Airtable probably hits the same demographic.
I think PlanetScale has got to work on their pricing model if the assumption is that it is ideal for that sort of an app (it's not "attractive" to switch right now & there's no pricing protection plans), but I'm not an economist or sales guy - like look at Google Fi bandwidth pricing for an example of where I overpay for data.
Great comparison, but i feel like it would be fair to mention support for foreign key constraints in the overview table (which planetscale doesn‘t have, afaik)
No transactions across shards is a bummer as well. Feels like planetscale might not be the best choice for small to medium projects, despite their improvements in developer experience.
Does anyone have a good reference to a comparison of the two products that isn't written by someone with a strong financial incentive for you to pick one over the other?
The “Trusted by” page has some pretty impressive flagship companies (GitHub, Slack, Square, AirBnb). Is anyone familiar with the role in which Planetscale is used at those companies? (Unless that is advertising users of vitess vs the hosted offering).
>> While RDS limits connections to 16,000 PlanetScale has been designed to scale upwards of 250,000 connections to a single database.
Curious to know what kind of applications would need more than 16,000 connections to a single database? In a typical application, that I know, a single database is connected by few replicated application servers. The count could vary from one to a few hundreds. I am not sure scaling the number of connections can solve the real scaling problem. Let’s say you support 250,000 connections and every connection is sending some queries at the same time. Is the database capable of handling that many queries, if not then what is the point of supporting so many connections.
This is how you beat Amazon/AWS, you go for the 40 percent where they fall behind in their products and make it better. They have a broad set of tooling not a particularly deep set of tooling.
The main issue that doesn't seem to be reflected here is that it's really hard to have a database and your application in different locations. Latency and security are big components in the general equation and both might be affected by this.
(This is the same reason why, although there are excellent Redis-as-a-service products, it's hard to justify to use them at all.)
16 comments
[ 2.4 ms ] story [ 50.7 ms ] threadNow if you're using other services, be aware of egress costs, which are not mentioned in the article.
I think PlanetScale is built for someone who isn't using raw machines to build an app or running a dev-ops org.
Something like Vercel+PlanetScale is more along the lines of tooling you're likely to use (or Heroku if you're dealing with existing code).
The egress costs are rarely an issue for API endpoints, unless you're serving assets out of the hosts.
There's a million intranet-like workflow apps which don't need the additional headache of maintaining an RDS (or the skills to secure IAM). Mostly state machines with click-next-to-continue - Airtable probably hits the same demographic.
I think PlanetScale has got to work on their pricing model if the assumption is that it is ideal for that sort of an app (it's not "attractive" to switch right now & there's no pricing protection plans), but I'm not an economist or sales guy - like look at Google Fi bandwidth pricing for an example of where I overpay for data.
"We make some things easier for developers but you will have to deal with concurrent updates in your application"
https://vitess.io/docs/reference/compatibility/mysql-compati...
4 years of Vitess in prod, also a maintainer
edit: see the case studies linked here https://planetscale.com/enterprise
Curious to know what kind of applications would need more than 16,000 connections to a single database? In a typical application, that I know, a single database is connected by few replicated application servers. The count could vary from one to a few hundreds. I am not sure scaling the number of connections can solve the real scaling problem. Let’s say you support 250,000 connections and every connection is sending some queries at the same time. Is the database capable of handling that many queries, if not then what is the point of supporting so many connections.
(This is the same reason why, although there are excellent Redis-as-a-service products, it's hard to justify to use them at all.)