Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PlanetScale for Postgres is now GA

planetscale.com

Post reply on HN
Print view View original

111–120 of 196 posts

Re: PlanetScale for Postgres is now GA

#111

Post by bri3d »

n_u wrote: post #103
bri3d wrote: post #89

Earlier quoted context omitted.

> I would highly recommend you read the docs on InnoDB locking then pick Postgres. This made me laugh pretty hard, but it's basically my take too. I'd pretty much go with the same thing. It's interesting to me, though, that people see Postgres as the "big database" and MySQL as the "hobby database." I basically see things as the exact opposite - Postgres is incredibly flexible, very nice to use, and these days, has f…

> This made me laugh pretty hard, but it's basically my take too. Haha glad you enjoyed it. > It's interesting to me, though, that people see Postgres as the "big database" and MySQL as the "hobby database." I basically see things as the exact opposite I agree. As I understand Postgres started as a challenger to SQL[1][2] with support for more complicated data types but then in the mid '90s they added SQL support and…

> I feel like the more I learn about database internals the more I learn about how MySQL did things the "right" way and Postgres's approach is a bit odd.

This is a good distinction too; I was thinking from the end-user’s standpoint, where Postgres has historically been seen as more faithful to both SQL standards and consistency guarantees.

Re: PlanetScale for Postgres is now GA

#112

Post by therein »

DarkNova6 wrote: post #72
richieartoul wrote: post #66

Earlier quoted context omitted.

It's not a landing page, it's a blog, and if you read the first few sentences of the post it becomes immediately clear what service PlanetScale provides.

The first few sentences mean absolutely squat. > Our mission is simple: bring you the fastest and most reliable databases with the best developer experience. We have done this for 5 years now with our managed Vitess product, allowing companies like Cursor, Intercom, and Block to scale beyond previous limits. > We are so excited to bring this to Postgres. Our proprietary operator allows us to bring the maturity of Pla…

Sounds like it is yet another Postgres cloud offering. It is a little cringe for them to self-congratulate and say "allowing companies like Cursor, Intercom, and Block to scale beyond previous limits".

Did any of these companies reach out to them and say "you know, we wouldn't have been able to scale beyond our previous limits without you, thank you so much guys you saved us". If not, this is so insincere that it is cringe.

Are they implying these other companies lacked knowledge and expertise to put their databases on machines with NVMe storage? Or is it that they chose to use their product? If it is the latter, they should just say these companies chose us, instead of emphasizing how they just couldn't scale past their previous limits without PlanetScale's help.

Re: PlanetScale for Postgres is now GA

#113

Post by maxenglander »

odie5533 wrote: post #42
dfee wrote: post #29

Earlier quoted context omitted.

i'll take the opposite side. i was very impressed with their website. the very first line: > The world’s fastest and most scalable cloud databases the second line: > PlanetScale brings you the fastest databases available in the cloud. Both our Postgres and Vitess databases deliver exceptional speed and reliability, with Vitess adding ultra scalability through horizontal sharding. i know exactly what they do. zero flu…

How is this different than Aurora Postgres or RDS Postgres?

There are a lot of differences between Aurora/RDS and PlanetScale I could talk about, some but I'll point to just one for now: PlanetScale offers Metal databases, which means blazing fast NVMe drives attached directly to the host where Postgres is running. This gives you faster reads and writes than what either Aurora or RDS can achieve with their network-attached block storage. Check out our benchmarks: https://planetscale.com/blog/benchmarking-postgres

Also, the architecture of Aurora is very different from PlanetScale's:

* AWS Aurora uses storage-level replication, rather than traditional Postgres replication. This architecture has the benefit that a change made on an Aurora primary is visible very quickly on the read replicas. * PlanetScale is a "shared nothing" architecture using what I would call traditional methods of data replication, where the primary and the replicas have independent copies of the data. This means that replication lag is a possibility customers must consider, whereas Aurora customers mostly ignore this. * If you set up 3 AWS RDS Postgres instances in separate availability zones and set up replication between them, that would be roughly similar to PlanetScale's architecture.

Re: PlanetScale for Postgres is now GA

#114

Post by t43562 »

odie5533 wrote: post #42
dfee wrote: post #29

Earlier quoted context omitted.

i'll take the opposite side. i was very impressed with their website. the very first line: > The world’s fastest and most scalable cloud databases the second line: > PlanetScale brings you the fastest databases available in the cloud. Both our Postgres and Vitess databases deliver exceptional speed and reliability, with Vitess adding ultra scalability through horizontal sharding. i know exactly what they do. zero flu…

How is this different than Aurora Postgres or RDS Postgres?

This is really what I meant. They must offer more than a copy of postgres running on a computer. How do they scale? What are the features? Why would I choose this over RDS for example?

Scaling postgres is not that informative. I am sorry if I annoyed the people working on it. I think the USP could be explained more obviously.

Re: PlanetScale for Postgres is now GA

#115

Post by t43562 »

maxenglander wrote: post #113
odie5533 wrote: post #42

Earlier quoted context omitted.

How is this different than Aurora Postgres or RDS Postgres?

There are a lot of differences between Aurora/RDS and PlanetScale I could talk about, some but I'll point to just one for now: PlanetScale offers Metal databases, which means blazing fast NVMe drives attached directly to the host where Postgres is running. This gives you faster reads and writes than what either Aurora or RDS can achieve with their network-attached block storage. Check out our benchmarks: https://plan…

This is an incredibly good example of what I wanted to know.

Re: PlanetScale for Postgres is now GA

#116

Post by samlambert »

therein wrote: post #112
DarkNova6 wrote: post #72

Earlier quoted context omitted.

The first few sentences mean absolutely squat. > Our mission is simple: bring you the fastest and most reliable databases with the best developer experience. We have done this for 5 years now with our managed Vitess product, allowing companies like Cursor, Intercom, and Block to scale beyond previous limits. > We are so excited to bring this to Postgres. Our proprietary operator allows us to bring the maturity of Pla…

Sounds like it is yet another Postgres cloud offering. It is a little cringe for them to self-congratulate and say "allowing companies like Cursor, Intercom, and Block to scale beyond previous limits". Did any of these companies reach out to them and say "you know, we wouldn't have been able to scale beyond our previous limits without you, thank you so much guys you saved us". If not, this is so insincere that it is…

happy to answer this with direct customer quotes from the companies you mentioned. all of these quotes are public:

"We chose PlanetScale to host our most demanding Vitess and Postgres workloads, doing millions of queries per second on hundreds of terabytes of data." – Sualeh Asif - Chief Product Officer @Anysphere (Cursor)

"Moving to PlanetScale added a 9 to our uptime." - Brian Scanlan @Intercom https://x.com/brian_scanlan/status/1963552743294967877

"In the past we've had issues when something unusual happens on a specific shard, resulting in spiked CPU and poor performance, and since migrating we haven't really seen instances of this, speaking to PlanetScale choosing the correct hardware for our existing load at the outset." - Aaron Young, Engineering Manager @block

It seems like you are reaching pretty hard to find an issue with this statement. Your comment seems to come from a lack of experience scaling databases and not understanding how difficult it is to do what we've done in partnership with our customers. Either that or deep or a high level of insincerity.

Re: PlanetScale for Postgres is now GA

#117

Post by rcrowley »

n_u wrote: post #106
rcrowley wrote: post #99

Earlier quoted context omitted.

I think we've got (1) covered elsewhere in the comment tree. For (2), semi-synchronous replication is a MySQL term which we realize in Postgres is by using synchronous replication with ANY one of the available replicas acknowledging the write. This allows us to guarantee durability in two availability zones before acknowledging writes to clients. In MySQL the _semi_ part of semi-synchronous replication refers to the…

> write only needing to be written to the binary log on the replica and not (necessarily) applied to InnoDB. Ah. I wonder are writes in the log but not yet in InnoDB are available for reads? Then your write may succeed but a subsequent read from a replica would not see it so you lose read-after-write consistency. Perhaps that's another tradeoff. I'll have to research a bit more but the MySQL docs [1] say "requires on…

A lagging replica, even one that just acknowledged a semi-sync write, will return stale results if you route a `SELECT` to it.

First and foremost, the extra copies of the data are for fault tolerance. In specific circumstances they may offer some slack capacity that you can use to serve (potentially stale) reads but they're never going to offer read-your-writes consistency.

The docs you quote are a bit obtuse but the "acknowledgement" is the row event being written to the binary log. "Fully executed and committed" is when it makes its way into InnoDB and becomes available for future reads.

Re: PlanetScale for Postgres is now GA

#118

Post by bri3d »

samlambert wrote: post #109
bri3d wrote: post #82

Earlier quoted context omitted.

* I saw your benchmark page at https://planetscale.com/benchmarks/aurora ; do you have something similar for Aurora Serverless? * Do you support something like Aurora Fast Cloning (whether a true CoW fast clone or detaching a replica _without_ promoting it into its own cluster / branch with its own replicas, incurring cost)? * Can PlanetScale Postgres set `max_standby_streaming_delay` to an indefinite amount? * The e…

it should be pretty much the same for aurora serverless and likely even cheaper. we see some astronomically expensive auorora serverless bills. We have not made max_standby_streaming_delay configurable yet. What's your use case? I don't fully parse your question about blue/green. can you expand your question please? is this for online updrades?

> I don't fully parse your question about blue/green. can you expand your question please? is this for online updrades?

Online upgrade or migration DDL - both use cases. I think Amazon's blue/green is effectively the same thing as your "branch-and-commit" strategy for schema migration. I was just looking for whether there's a significant difference.

> We have not made max_standby_streaming_delay configurable yet. What's your use case?

This goes with

>> Do you support something like Aurora Fast Cloning (whether a true CoW fast clone or detaching a replica _without_ promoting it into its own cluster / branch with its own replicas, incurring cost)?

The use case is mixing transaction processing and long-running queries/analytics in the same database using read replicas. The easiest way to do this in a native Postgres cluster is by using a "soft-real-time" read-replica with max_standby_streaming_delay set to `-1`, which is allowed to fall behind worst-case by the duration of a dashboard query and then keep up again.

This doesn't work in environments with more esoteric SAN-based replication strategies like Aurora, where max_standby_streaming_delay can't go beyond 30 seconds. In this case we have to use some combination of strategies: making CoW clones for each analytics task, architecting data to avoid leader/replication conflicts, for example by using partitioning, retrying replica queries until they don't access hot rows, or falling back to traditional analytics/data warehouse solutions at the application or logical replication layer. Not having to do these things would be a nice benefit over Aurora.

Re: PlanetScale for Postgres is now GA

#119

Post by maxenglander »

therein wrote: post #112
DarkNova6 wrote: post #72

Earlier quoted context omitted.

The first few sentences mean absolutely squat. > Our mission is simple: bring you the fastest and most reliable databases with the best developer experience. We have done this for 5 years now with our managed Vitess product, allowing companies like Cursor, Intercom, and Block to scale beyond previous limits. > We are so excited to bring this to Postgres. Our proprietary operator allows us to bring the maturity of Pla…

Sounds like it is yet another Postgres cloud offering. It is a little cringe for them to self-congratulate and say "allowing companies like Cursor, Intercom, and Block to scale beyond previous limits". Did any of these companies reach out to them and say "you know, we wouldn't have been able to scale beyond our previous limits without you, thank you so much guys you saved us". If not, this is so insincere that it is…

> instead of emphasizing how they just couldn't scale past their previous limits.

We are not saying that our customers don't have the knowledge or expertise to do what we do. Many of our customers, including the ones mentioned above, have exceptionally high levels of expertise and talent.

Even so, it is not a contradiction to say that we allowed them to scale beyond their previous limits. In some cases those limits were that their previous DBaaS providers simply lacked the ability to scale horizontally or provide blazing fast reads and writes the way we do out of the box. In other cases, we offer a degree of reliability and uptime that exceeded what customers' previous DBaaS could provide. Just two name a couple of limits customers have run into before choosing PlanetScale.

Expertise and know-how, and actually doing the thing, are different. Many of our customers who are technically capable of doing what we do would simply prefer to focus their knowledge and expertise building their core product, and let the database experts (that's us) do the databasing.

Re: PlanetScale for Postgres is now GA

#120

Post by therein »

samlambert wrote: post #116
therein wrote: post #112

Earlier quoted context omitted.

Sounds like it is yet another Postgres cloud offering. It is a little cringe for them to self-congratulate and say "allowing companies like Cursor, Intercom, and Block to scale beyond previous limits". Did any of these companies reach out to them and say "you know, we wouldn't have been able to scale beyond our previous limits without you, thank you so much guys you saved us". If not, this is so insincere that it is…

happy to answer this with direct customer quotes from the companies you mentioned. all of these quotes are public: "We chose PlanetScale to host our most demanding Vitess and Postgres workloads, doing millions of queries per second on hundreds of terabytes of data." – Sualeh Asif - Chief Product Officer @Anysphere (Cursor) "Moving to PlanetScale added a 9 to our uptime." - Brian Scanlan @Intercom https://x.com/brian_…

> It seems like you are reaching pretty hard to find an issue with this statement. Your comment seems to come from a lack of experience scaling databases and not understanding how difficult it is to do what we've done in partnership with our customers. Either that or deep or a high level of insincerity.

Up until this, I was gonna say, fair enough, I appreciate the direct replies from the staff.

But this paragraph settles it for me: PlanetScale as a company has a narcissistic personality which is fine for some I guess. Hopefully one day you will have a product that justifies that huge ego.

Post reply on HN