PlanetScale for Postgres is now GA • Hacker News Board

Re: PlanetScale for Postgres is now GA

#31

Post by fosterfriends » Mon, Sep 22, 2025, 4:24 PM UTC

Congrats on the launch Sam! Excited to try it out for Graphite's production DB

Re: PlanetScale for Postgres is now GA

#32

Post by game_the0ry » Mon, Sep 22, 2025, 4:26 PM UTC

dangoodmanUT wrote: post #9

ritzaco wrote: post #7

This seems to be mainly aimed at existing PlanetScale customers. > To create a Postgres database, sign up or log in to your PlanetScale account, create a new database, and select Postgres. It does mention the sign up option but doesn't really give me much context about pricing or what it is. I know a bit, but I get confused by different database offerings, so it seems like a missed opportunity to give me two more sen…

PlanetScale isnt' really designed for the "ill give it a go" casual customer that might use supabase It's designed for businesses that need to haul ass

I am not experienced enough to know the performance differences between planetscale and supabase, but...

> It's designed for businesses that need to haul ass

Could you elaborate what you meant by this for my education?

Re: PlanetScale for Postgres is now GA

#33

Post by hollylawly » Mon, Sep 22, 2025, 4:27 PM UTC

samlambert wrote: post #10

dangoodmanUT wrote: post #6

Earlier quoted context omitted.

Postgres (esoterically?) has some issues with index bloat on high-insert workloads, does PlanetScale do anything special to tune for this by default, since it caters to higher-perf workloads (over something like supabase)?

We don't do anything special (yet) but we do have bloat detection that we warn you about. We've noticed that autovacuum works very well on our Metal product because of the extra resources.

More information about bloat detection here: https://planetscale.com/docs/postgres/monitoring/schema-reco...

Re: PlanetScale for Postgres is now GA

#34

Post by samlambert » Mon, Sep 22, 2025, 4:28 PM UTC

game_the0ry wrote: post #32

dangoodmanUT wrote: post #9

Earlier quoted context omitted.

PlanetScale isnt' really designed for the "ill give it a go" casual customer that might use supabase It's designed for businesses that need to haul ass

I am not experienced enough to know the performance differences between planetscale and supabase, but... > It's designed for businesses that need to haul ass Could you elaborate what you meant by this for my education?

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

Re: PlanetScale for Postgres is now GA

#35

Post by theanirudh » Mon, Sep 22, 2025, 4:29 PM UTC

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 things up further. Early days, but so far so good.

Re: PlanetScale for Postgres is now GA

#36

Post by petergeoghegan » Mon, Sep 22, 2025, 4:31 PM UTC

dangoodmanUT wrote: post #6

samlambert wrote: post #2

If anyone has questions about our Postgres product please feel free to ask. I will be around to answer.

Postgres (esoterically?) has some issues with index bloat on high-insert workloads, does PlanetScale do anything special to tune for this by default, since it caters to higher-perf workloads (over something like supabase)?

Can you provide more detail/a reference?

I've done extensive work on improving the Postgres B-Tree code, over quite a number of releases. I'm not aware of any problems with high-insert workloads in particular. I have personally fixed a number of subtle issues that could lead to lower space utilization with such workloads [1][2] in the past, though.

if there's a remaining problem in this area, then I'd very much like to know about it.

[1] https://www.youtube.com/watch?v=p5RaATILoiE [2] https://speakerdeck.com/peterg/nbtree-arch-pgcon

Re: PlanetScale for Postgres is now GA

#37

Post by awaseem » Mon, Sep 22, 2025, 4:38 PM UTC

Might be a dumb question, but what is metal? Are you folks hosting DBs on your own infra or still going through AWS/GCP

Re: PlanetScale for Postgres is now GA

#38

Post by mattrobenolt » Mon, Sep 22, 2025, 4:39 PM UTC

awaseem wrote: post #37

Might be a dumb question, but what is metal? Are you folks hosting DBs on your own infra or still going through AWS/GCP

It's still AWS/GCP, but it uses instance types with local NVMes.

Re: PlanetScale for Postgres is now GA

#39

Post by samlambert » Mon, Sep 22, 2025, 4:40 PM UTC

awaseem wrote: post #37

Might be a dumb question, but what is metal? Are you folks hosting DBs on your own infra or still going through AWS/GCP

hosting on AWS/GCP on the ephemeral NVMe nodes. https://planetscale.com/metal

Re: PlanetScale for Postgres is now GA

#40

Post by benterix » Mon, Sep 22, 2025, 4:41 PM UTC

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?