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

141–150 of 196 posts

Re: PlanetScale for Postgres is now GA

#141

Post by xnickb »

therein wrote: post #138
samlambert wrote: post #129

Earlier quoted context omitted.

you made a dumb comment and got heat for it. i don't think that represents a narcissistic personality. regardless of what you think of us i wish you all the best.

Oh I got the heat for it? From you? I felt none of it. Way to represent your employer weird champ. It is wild that an employee (lmao CEO) posts this way and it is sanctioned by his employer. I guess you're used to talking this way to your employees. But I am not an employee, so I can't feel your fury. I am glad it is taking place in public, I can only imagine how poorly you must treat people behind closed doors. At l…

Oh come on now, no one reads this deep into the conversation.

Sigh.

Re: PlanetScale for Postgres is now GA

#142

Post by bentohn »

We were in the beta for this and they've been great.

We're presently in a migration for our larger instances on Heroku, but were able to test on a new product (fairly high writes/IOPs) and it's been nice to have more control vs. Heroku (specifically, ability to just buy more IOPs or storage).

Had one incident during the beta which we believed we caused on our own but within 5 minutes of pinging them they had thrown multiple engineers on it to debug and resolve quickly. For me, that's the main thing I care about with managed DB services as most tech is commoditization at this point.

Just wish the migration path from Heroku was a tad easier (Heroku blocks logical replication on all instances) but pushing through anyway because I want to use the metal offering.

Re: PlanetScale for Postgres is now GA

#143

Post by jashmatthews »

bri3d wrote: post #108
jedberg wrote: post #63

Earlier quoted context omitted.

At this point I'm not sure why anyone would choose MySQL. Any advantage it had pretty much evaporated with these hosted solutions. For example, MySQL was easier to get running and connect to. These cloud offerings (Planetscale, Supabase, Neon, even RDS) have solved that. MySQL was faster for read heavy loads. Also solved by the cloud vendors.

At large scale I'd say MySQL is still a competitor for a few reasons: * Scale-out inertia: yes, cloud vendors provide similar shading and clustering features for Postgres, but they're all a lot newer. * Thus, hiring. It's easier to find extreme-scale MySQL experts (although this erodes year by year). * Write amplification, index bloat, and tuple/page bloat for extremely UPDATE heavy workloads. It is what it is. Postg…

> hybrid OLAP+OLTP .... in Postgres this pattern requires careful planning to avoid falling afoul of max_standby_streaming_delay for example

This is a really gnarly problem at scale I've rarely seen anyone else bring up. Either you use max_standby_streaming_delay and queries that conflict with replication cause replication to lag or you use hot_standby_feedback and long running queries on the OLAP replica cause problems on the primary.

Logical Decoding on a replica in also needs hot standby feedback which is a giant PITA for your ETL replica.

Re: PlanetScale for Postgres is now GA

#144

Post by siquick »

benterix wrote: post #40
theanirudh wrote: post #35

We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty smooth. Post-migration we hit a few issues (turned out it wasn't an issue with PlanetScale), and the PlanetScale team jumped in immediately to help us out, even on a Saturday morning so support's been amazing. The Insights tab also surfaced missing indexes we added, which sped thin…

Out of curiosity: how do you connect your databases to external services that are consuming these data? In places I do similar work, databases are usually in the same private network as the instances which are reading and writing data to them. If you put them somewhere on the internet, apart from security, doesn't it affect latency?

This is the thought I always come back to with the non-big cloud services. It’s pretty much always been mandatory at non-startups to have all databases to be hidden away from the wider internet.

Re: PlanetScale for Postgres is now GA

#145

Post by jedberg »

bri3d wrote: post #108
jedberg wrote: post #63

Earlier quoted context omitted.

At this point I'm not sure why anyone would choose MySQL. Any advantage it had pretty much evaporated with these hosted solutions. For example, MySQL was easier to get running and connect to. These cloud offerings (Planetscale, Supabase, Neon, even RDS) have solved that. MySQL was faster for read heavy loads. Also solved by the cloud vendors.

At large scale I'd say MySQL is still a competitor for a few reasons: * Scale-out inertia: yes, cloud vendors provide similar shading and clustering features for Postgres, but they're all a lot newer. * Thus, hiring. It's easier to find extreme-scale MySQL experts (although this erodes year by year). * Write amplification, index bloat, and tuple/page bloat for extremely UPDATE heavy workloads. It is what it is. Postg…

I appreciate your detailed reply, and I agree with all your points.

I am however highly amused that everyone in this thread defending MySQL ends with some form of "I'd still choose Postgres though!". :)

Re: PlanetScale for Postgres is now GA

#146

Post by bourbonproof »

mattrobenolt wrote: post #50
fourseventy wrote: post #46

The way I understood NVMe drives to work on Google Cloud is that they are ephemeral and your data will be lost if the vm reboots. How do they work in this case?

We deal with this by always running 3 nodes in a cluster, one per AZ, and strong backup/restore processes. So yes, the data per-node is ephemeral, but it is redundant and durable for the whole cluster.

Do I understand this right: if these 3 nodes shutdown for some reason, all data is lost and you have to actually restore from backup instead of just starting the machine again. And even if you have to restart one node (due to updates, or crashes) you also have to restore from backup? If so, why not pick a hosting provider that doesn't wipe the disk when machine shuts down?

Re: PlanetScale for Postgres is now GA

#147

Post by parthdesai »

ndriscoll wrote: post #123
samlambert wrote: post #34

Earlier quoted context omitted.

Performance differences between PlanetScale and Supabase: https://planetscale.com/benchmarks/supabase

> Businesses that need to haul ass > Benchmarks are done on a dual-core VM with "unlimited" IOPS I'd be interested in a comparison with a pair of Beelink SER5 Pros ($300 each) in master-slave config.

> > Benchmarks are done on a dual-core VM with "unlimited" IOPS

Unlimited is a feature here, no need to be snarky. They famously went against the accepted practice of separating storage from compute, and as a result, you reduce latency by an order of magnitude and get unlimited IOPS.

Re: PlanetScale for Postgres is now GA

#148

Post by jedberg »

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…

> This is a bit confusing to me because MySQL was released around the same time Postgres added SQL support but maybe it was because MySQL had a company behind it.

I think the main reason MySQL took off faster than Postgres originally is because it had better defaults. MySql worked out of the box on modern hardware. Postgres assumed you only have 4MB of memory until well into the 2010s, in part to make it keep running on everything it ever ran on in the past.

So when you first installed Postgres, it would perform terribly until you optimized it.

It's really a fantastic case study in setting good defaults.

Re: PlanetScale for Postgres is now GA

#149

Post by parthdesai »

benjiro wrote: post #130
cyberpunk wrote: post #88

Earlier quoted context omitted.

This isn’t any kind of answer it’s a bunch of non-statements.. How is this any different that rds on nvme disks? With a name like planet scale i assumed it would be some multi-master setup?

Planetscale used to run postgres on AWS with network attached storage. So every time the DB hits the disks > it goes over the network. Need to read 4kb > network, another 4kb > network. So your latency is instead of microsecond on local storage, its miliseconds. Where a local NVME can do ... 100k 4k reads, over the network storage it does maybe 1k (just a example). The problem is, there are not a lot of solutions to…

> Side node: The guy that wrote Vitess for Mysql, is also working on multigress (https://multigres.com/), a solution that does the same. Aka Vitess for postgres.

And also was the founder of planetscale

Re: PlanetScale for Postgres is now GA

#150

Post by sgarland »

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…

> Are they implying these other companies lacked knowledge and expertise to put their databases on machines with NVMe storage?

Have you worked at any web dev companies? Of the ones I’ve been at, precisely one had any desire to run their own DBs, and deaf was more out of necessity due to poor schema design needing local NVMe just to stay afloat.

Yes, most web companies lack the experience to touch a server, because their staff are all cloud-native, and their CTOs have drank the Kool-Aid and are convinced that it’s dangerous and risky to manage a server.

Post reply on HN