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

121–130 of 196 posts

Re: PlanetScale for Postgres is now GA

#121

Post by n_u »

rcrowley wrote: post #117
n_u wrote: post #106

Earlier quoted context omitted.

> 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…

Ah yeah that makes sense. I guess if you are only using replica for fault tolerance and not as a read-replica then it seems semi-synchronous replication is strictly better than synchronous replication. I suppose in semi-sync the failover will take a little longer but it's probably inconsequential.

Thanks!

Re: PlanetScale for Postgres is now GA

#122

Post by maxenglander »

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?

In addition to the point about performance Sam made, PlanetScale's Vitess (MySQL) offers out-of-the-box horizontal scalability, which means we can maintain extremely good performance as your dataset and QPS grows to a massive scale: https://planetscale.com/case-studies/cash-app. We will be bringing the same capability to Postgres later on.

Our uptime and reliability is also higher than what you might find elsewhere. It's not uncommon for companies paying lots of money to operate elsewhere to migrate to PlanetScale for that reason.

We're a serious database for serious businesses. If a business can't afford to spend $39/mo to try PlanetScale, they may be happier operating elsewhere until their business grows to a point where they are running into scaling and performance limits and can afford (or badly need, depending on the severity of those limits) to try us out.

Re: PlanetScale for Postgres is now GA

#123

Post by ndriscoll »

samlambert wrote: post #34
game_the0ry wrote: post #32

Earlier quoted context omitted.

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

> 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.

Re: PlanetScale for Postgres is now GA

#124

Post by rimprobablyly »

intelekshual wrote: post #12
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 (famously?) deprecated their free "Hobby" tier (plus fired their sales & marketing teams) back in 2024 to achieve profitability https://planetscale.com/blog/planetscale-forever

> famously?

Notoriously

Re: PlanetScale for Postgres is now GA

#125

Post by apavlo »

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…

You are conflating MySQL and InnoDB. The latter does a lot of good things, much more than the former.

Re: PlanetScale for Postgres is now GA

#126

Post by tracker1 »

n_u wrote: post #65
attentionstinks wrote: post #14

Earlier quoted context omitted.

How should one decide whether to go with MySQL or Postgres for a greenfield project?

From my position MySQL pros: The MySQL docs on how the default storage engine InnoDB locks rows to support transaction isolation levels is fantastic. [1] This can help you better architect your system to avoid lock contention or understand why existing queries may be contending for locks. As far as I know Postgres does not have docs like that. MySQL uses direct I/O so it disables the OS page cache and uses its own bu…

To me, every time I've touched MySQL, I've found an issue that just rubbed me the wrong way... starting with the fact that UTF8 isn't, and even across new major versions hasn't changed to an alias for the real UTF8. (VAR)BINARY does case sensitive collation based on db default, it shouldn't do any type of textual comparison even if the data is "text". You can't do foreign keys with ANSI quotes for the table/field names...

Note: some of this may have changed in the past 6+ years I've avoided looking at it again.

Re: PlanetScale for Postgres is now GA

#127

Post by shivasaxena »

therein wrote: post #120
samlambert wrote: post #116

Earlier quoted context omitted.

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 set…

[dead]

Re: PlanetScale for Postgres is now GA

#128

Post by cortesoft »

jedberg wrote: post #102
cortesoft wrote: post #94

Earlier quoted context omitted.

> At this point I'm not sure why anyone would choose MySQL Because I have used MySQL for over 20 years and it is what I know!

Fair enough, but I assume most of that is in the administration of MySQL? Which is all now abstracted away by the cloud vendors. If you're running it yourself I could see why you'd do that, but if you're mostly just using it now, Postgres can do all the same things in the database pretty much the same way, plus a whole lot more.

Its both operating MySQL and creating applications that use it.

Additionally, almost all my workloads run in our own datacenters, so I haven't yet been able to offload the administration bits to the cloud.

Re: PlanetScale for Postgres is now GA

#129

Post by samlambert »

therein wrote: post #120
samlambert wrote: post #116

Earlier quoted context omitted.

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 set…

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.

Re: PlanetScale for Postgres is now GA

#130

Post by benjiro »

cyberpunk wrote: post #88
brettgriffin wrote: post #85

Earlier quoted context omitted.

Literally the first line of every line on the site: > PlanetScale is the world’s fastest relational database platform. We offer PostgreSQL and Vitess databases that run on NVMe-backed nodes to bring you scale, performance, reliability, and cost-efficiencies — without sacrificing developer experience. > PlanetScale is a relational database platform that brings you scale, performance, and reliability — without sacrific…

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 scale postgres beyond a single server. So if your DB grows to 100TB ... you have a issue as AWS does not provide a 100TB local NVME solution, only network storage.

Here comes Niki or whatever they named it. Their own alternative to Vitess (see Mysql), what is a solution that allows Mysql to scale horizontally from 1 to 1000's of servers, each with their own local storage.

So Planetscale made their own solution, so they can horizontal scale dozens, hundreds of AWS VPS with their own local storage, to give you those 100, 200, 500TB of storage space, without the need for network based storage.

There are other solutions like CockroachDB, YukubyteDB, TiDB that also allow for horizontal scaling but non are 100% postgres (and especially extensions) compatible.

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.

So yea, hope this helps a bit to explain it. If your not into dealing with DB scaling, the way they wrote it is really not helpful.

Post reply on HN