Live data from Hacker News

PlanetScale is now generally available

planetscale.com

41–50 of 139 posts

Re: PlanetScale is now generally available

#41
post #29
post #20

Earlier quoted context omitted.

Thanks, that looks pretty useful. To me, this means that planetscale (and vitess) immediately become less useful for a large class of applications: existing apps that use an RDBMS that you want to scale. Because most existing apps will expect FKs. I haven't tested my employer's application (which has FKs) to see what will happen, but I doubt it will be smooth sailing. But there's probably plenty of greenfield develop…

There is not and will never be a solution to the problem of horizontally scaling an application and database designed jointly for a single-box ACID RDBMS. You have to compromise something to get the scaling.

What is the compromise of Cockroach DB?

Re: PlanetScale is now generally available

#42
post #29
post #20

Earlier quoted context omitted.

Thanks, that looks pretty useful. To me, this means that planetscale (and vitess) immediately become less useful for a large class of applications: existing apps that use an RDBMS that you want to scale. Because most existing apps will expect FKs. I haven't tested my employer's application (which has FKs) to see what will happen, but I doubt it will be smooth sailing. But there's probably plenty of greenfield develop…

There is not and will never be a solution to the problem of horizontally scaling an application and database designed jointly for a single-box ACID RDBMS. You have to compromise something to get the scaling.

Depends on your definition of horizontally scaling and the inherent size limitations you would be willing to accept.

CitusDB for example handles this by allowing FKeys between tables that share the same partition key. However it's also not -as- scalable as Vitess or as georeplication friendly but for many uses that need "more than a single box" is probably enough scalability.

Re: PlanetScale is now generally available

#43
post #17

Earlier quoted context omitted.

I'm curious about what kind of workloads people would be using a serverless DB for? If I understand it correctly, let's say my DB is only being used to process 1M transactions from 9am-1pm, I'm basically only paying for the load during that time, versus a managed DB where it's being paid to be on 24/7. With most serverless there is a penalty though - cold startup. So is it purely an economic play for esoteric DB work…

Lower operational burden - if you're using a serverless db maintaining servers is one less thing to think about. Same with any infrastructure - you don't have to worry about orchestration, load balancing, authentication, etc.

I mean, I can essentially do this with any PaaS DB, no? RDS, Azure SQL, Cosmos, etc.

Re: PlanetScale is now generally available

#45
post #41
post #29

Earlier quoted context omitted.

There is not and will never be a solution to the problem of horizontally scaling an application and database designed jointly for a single-box ACID RDBMS. You have to compromise something to get the scaling.

What is the compromise of Cockroach DB?

Heavy toll on performance and is not really postgres. For the same workload pg can be up to 30x faster or more than cockroach. At some point of course, pg won't be able to keep up and the horizontal scaling of crdb will beat it.

Re: PlanetScale is now generally available

#46

I am having trouble understanding what a "Serveless Database" is. When I do a search of the term, I get hype, not a definition. For example: "What is Serverless Database? Serverless Database is a prerequisite for Serverless Computing. These are specially designed for the workloads which are unpredictable and can change rapidly. What’s more? This allows you to pay only for the database resources you use, on a second-b…

"Serverless" just seems to be the trendy rebranding of "as a service".

Re: PlanetScale is now generally available

#47
post #39

Earlier quoted context omitted.

I wonder how this stacks up against CockroachDB.

To the best of my knowledge the scaling behind distributed ranged KV stores (which cockroachDB uses as its storage engine) is easier to manage overall. Whether that's important for "serverless" is another question. I'm sure PlanetScale will help with rebalancing and re-sharding but, just like FoundationDB, CockroachDB "promises" to automatically re-shard hot keys and ranges for you under the hood, and so _in theory_…

Vitess using range based sharding and with a single command of `Reshard` you can split a range to n sub-ranges.

Ref for how command looks like https://vitess.io/docs/user-guides/configuration-advanced/re...

Re: PlanetScale is now generally available

#49
post #29
post #20

Earlier quoted context omitted.

Thanks, that looks pretty useful. To me, this means that planetscale (and vitess) immediately become less useful for a large class of applications: existing apps that use an RDBMS that you want to scale. Because most existing apps will expect FKs. I haven't tested my employer's application (which has FKs) to see what will happen, but I doubt it will be smooth sailing. But there's probably plenty of greenfield develop…

There is not and will never be a solution to the problem of horizontally scaling an application and database designed jointly for a single-box ACID RDBMS. You have to compromise something to get the scaling.

What about CockroachDB and YugabyteDB?

Re: PlanetScale is now generally available

#50
post #30

>What’s more? This allows you to pay only for the database resources you use, on a second-by-second basis. ..." This is the biggest sham in technology offerings today. The idea that you only pay what you use is a misnomer.

Right, should be resources you "reserve".
Post reply on HN