To make it shorter than OP's reply, from my understanding of the offerings:
- PlanetScale for predictable load. You pick a config (CPU, memory) and if you don't have traffic it sits idle, and if you have traffic it's limited by the config you picked.
- Neon for scalability. You pay for compute hours, so if your traffic is spikey (e.g. concert ticket sales), you don't pay for idle resources during low traffic, and get all the compute you need during high traffic.
Except: "The active time includes periods when the database is receiving requests and for a duration (default 300 seconds) after the last request is received. Following this period of inactivity, the database scales down to zero, effectively pausing compute time billing."
So if you get at least one request every five minutes, neon will charge you for 24 hours of compute a day.
I use Postgres on RDS. Our database is several TB and runs a 24/7 production app. It seems fine. (earnest question) Why should I look into either/both of these?
Some slightly outdated information from PlanetScale [1] Especially now the have Postgres offering as well but most are still relevant. Most people would actually find cost reduction migrating. Similar story with Neon although I am more bias towards PS.
It is not that RDS dont work well. I think it is AWS being too greedy with their pricing and we have finally reached a point where it breaks our mental model on cost evaluation. And people are starting to look at alternatives.
Neon has leaned hard into AI and promoting vibe coding, example [0]. I assume they’ve also struggled with uptime, but don’t know.
Sam Lambert tweeted this [1], which may or may not (I genuinely have no idea) have been poking at Neon, or maybe just the idea of vibe coding in general.
IMO, reading [0], Neon (and most of the industry tbf) is suggesting bonkers ideas. “Oh, did the AI accidentally give you SQL Injection? No problem, we’ll catch it.” Maybe - just spitballing here - if you don’t know how to prevent the most basic of attacks, you have zero business putting anything into prod, and need to spend time learning fundamentals.
Long story short, I didn't want to make that analysis/distinction because it would miss the point.
They excel in their respective areas based on the architectural decisions they've made for the use cases they wanted to optimize for.
PlanetScale, with their latest Metal introduction, optimized for super low latency (they act like they've reinvented the wheel, lol), but they clearly have something in mind going in this direction.
Neon offers many managed features for serverless PostgreSQL that were missing in the market, like instant branching, and with auto-scaling, you may perform better with variable workloads. From their perspective, they wanted to serve other use cases.
There's no reason to always compare apples to oranges, and no reason to hate one another when everyone is pushing the managed database industry forward.
PlanetScale, with their latest Metal introduction, optimized for super low latency (they act like they've reinvented the wheel, lol), but they clearly have something in mind going in this direction.
I’ve spoken to them personally, and didn’t get the impression at all that they think they’ve “re-invented the wheel.” More like they realized that separating compute and storage was a god-awful idea, and are bringing back how things used to be in the days of boring tech.
Also, re: branching, PS MySQL definitely has that. I assume they’ll bring it to Postgres.
Bear in mind I have a large bias towards performance, and am a DBRE, so I also have strong opinions about normalization.
Separating compute and storage means that if you ever have to hit the disk - which is every time for writes, and depending on your working set size, often for reads as well - you’re getting a massive latency hit. I’ll use Amazon Aurora as an example, because they’re quite open with their architecture design, they’re the largest player in this space, and I’m personally familiar with it.
Aurora’s storage layer consists of 6 nodes split across 3 AZs. For a write to be counted as durable, it needs to be ack’d by 4/6 nodes, which means 2/3 AZs. That’s typically a minimum of 1 msec, though they do get written in parallel, which helps. 1 msec may not sound like much, but it’s an eternity for traditional SSD access.
MySQL is even worse with Aurora, because of its change buffer. Normally, writes (including deletes) to indexed columns (secondary indices) results in the changes to the indices being buffered, which avoids random I/O. Since Aurora's architecture is so wildly different than vanilla MySQL, it can't do that, and all writes to secondary indices must happen synchronously.
Given most SaaS companies' tendency to eschew RDBMS expertise in favor of full-stack teams, and those teams' tendency to use JSON[B] for everything, poor normalization practices, and sub-optimal queries, all of this adds up to a disastrous performance experience.
I have a homelab with Dell R620s, which originally came out in 2012. Storage is via Ceph on Samsung PM983 NVMe drives, connected with Mellanox ConnectX3-Pro in a mesh. These drives are circa-2013. Despite the age of this system, it has consistently out-performed Aurora MySQL and Postgres in benchmarks I've done. The only instance classes that can match it are, unsurprisingly, those with local NVMe storage.
In fairness, it isn't _all_ awful. Aurora does have one feature that is extremely nice: survivable page cache. If an instance restarts, in most circumstances, you don't lose the buffer pool / shared buffers on the instance. This means you don't have the typical cold start performance hit. That is legitimately cool tech, and quite useful. I'm less sold on the other features, like auto-scaling. If you're planning for a peak event (e.g. a sales event for e-commerce), you know well in advance, and have plenty of time to bring new instances online. If you have a surprise peak event, auto-scaling is going to take 30 minutes to 1 hour for the new instances to come online, which is an extremely long time to be sitting in a degraded state. This isn't really any faster than RDS, though again to Aurora's credit, the fact that all instances share the same underlying cluster volume means that there is no delay when pulling in blocks from S3.
Finally, Aurora’s other main benefit, as I alluded to, is that its shared cluster volume means that replication lag is typically quite low; 10-30 msec IME. However, also IME, devs don’t design apps around this, and anything other than instantaneous is too slow, so it doesn’t really matter.
Comments
Hm I feel like I jumped into the middle of something and don't understand the conclusion.
What's the beef between PlanetScale and Neon? Benchmarking, uptime, vibe coding?
The quote at the end doesn't really help me. Which one is good for what?
To make it shorter than OP's reply, from my understanding of the offerings:
- PlanetScale for predictable load. You pick a config (CPU, memory) and if you don't have traffic it sits idle, and if you have traffic it's limited by the config you picked.
- Neon for scalability. You pay for compute hours, so if your traffic is spikey (e.g. concert ticket sales), you don't pay for idle resources during low traffic, and get all the compute you need during high traffic.
Except: "The active time includes periods when the database is receiving requests and for a duration (default 300 seconds) after the last request is received. Following this period of inactivity, the database scales down to zero, effectively pausing compute time billing."
So if you get at least one request every five minutes, neon will charge you for 24 hours of compute a day.
I use Postgres on RDS. Our database is several TB and runs a 24/7 production app. It seems fine. (earnest question) Why should I look into either/both of these?
Some slightly outdated information from PlanetScale [1] Especially now the have Postgres offering as well but most are still relevant. Most people would actually find cost reduction migrating. Similar story with Neon although I am more bias towards PS.
It is not that RDS dont work well. I think it is AWS being too greedy with their pricing and we have finally reached a point where it breaks our mental model on cost evaluation. And people are starting to look at alternatives.
[1] https://planetscale.com/blog/planetscale-vs-amazon-rds
Neon has leaned hard into AI and promoting vibe coding, example [0]. I assume they’ve also struggled with uptime, but don’t know.
Sam Lambert tweeted this [1], which may or may not (I genuinely have no idea) have been poking at Neon, or maybe just the idea of vibe coding in general.
IMO, reading [0], Neon (and most of the industry tbf) is suggesting bonkers ideas. “Oh, did the AI accidentally give you SQL Injection? No problem, we’ll catch it.” Maybe - just spitballing here - if you don’t know how to prevent the most basic of attacks, you have zero business putting anything into prod, and need to spend time learning fundamentals.
[0]: https://neon.com/blog/oops-proof-your-vibe-code-with-neon-be...
[1]: https://x.com/isamlambert/status/1935333197635588393
Long story short, I didn't want to make that analysis/distinction because it would miss the point.
They excel in their respective areas based on the architectural decisions they've made for the use cases they wanted to optimize for.
PlanetScale, with their latest Metal introduction, optimized for super low latency (they act like they've reinvented the wheel, lol), but they clearly have something in mind going in this direction.
Neon offers many managed features for serverless PostgreSQL that were missing in the market, like instant branching, and with auto-scaling, you may perform better with variable workloads. From their perspective, they wanted to serve other use cases.
There's no reason to always compare apples to oranges, and no reason to hate one another when everyone is pushing the managed database industry forward.
I’ve spoken to them personally, and didn’t get the impression at all that they think they’ve “re-invented the wheel.” More like they realized that separating compute and storage was a god-awful idea, and are bringing back how things used to be in the days of boring tech.
Also, re: branching, PS MySQL definitely has that. I assume they’ll bring it to Postgres.
Why is it an awful idea? I don't understand the trade-offs well.
Bear in mind I have a large bias towards performance, and am a DBRE, so I also have strong opinions about normalization.
Separating compute and storage means that if you ever have to hit the disk - which is every time for writes, and depending on your working set size, often for reads as well - you’re getting a massive latency hit. I’ll use Amazon Aurora as an example, because they’re quite open with their architecture design, they’re the largest player in this space, and I’m personally familiar with it.
Aurora’s storage layer consists of 6 nodes split across 3 AZs. For a write to be counted as durable, it needs to be ack’d by 4/6 nodes, which means 2/3 AZs. That’s typically a minimum of 1 msec, though they do get written in parallel, which helps. 1 msec may not sound like much, but it’s an eternity for traditional SSD access.
MySQL is even worse with Aurora, because of its change buffer. Normally, writes (including deletes) to indexed columns (secondary indices) results in the changes to the indices being buffered, which avoids random I/O. Since Aurora's architecture is so wildly different than vanilla MySQL, it can't do that, and all writes to secondary indices must happen synchronously.
Given most SaaS companies' tendency to eschew RDBMS expertise in favor of full-stack teams, and those teams' tendency to use JSON[B] for everything, poor normalization practices, and sub-optimal queries, all of this adds up to a disastrous performance experience.
I have a homelab with Dell R620s, which originally came out in 2012. Storage is via Ceph on Samsung PM983 NVMe drives, connected with Mellanox ConnectX3-Pro in a mesh. These drives are circa-2013. Despite the age of this system, it has consistently out-performed Aurora MySQL and Postgres in benchmarks I've done. The only instance classes that can match it are, unsurprisingly, those with local NVMe storage.
In fairness, it isn't _all_ awful. Aurora does have one feature that is extremely nice: survivable page cache. If an instance restarts, in most circumstances, you don't lose the buffer pool / shared buffers on the instance. This means you don't have the typical cold start performance hit. That is legitimately cool tech, and quite useful. I'm less sold on the other features, like auto-scaling. If you're planning for a peak event (e.g. a sales event for e-commerce), you know well in advance, and have plenty of time to bring new instances online. If you have a surprise peak event, auto-scaling is going to take 30 minutes to 1 hour for the new instances to come online, which is an extremely long time to be sitting in a degraded state. This isn't really any faster than RDS, though again to Aurora's credit, the fact that all instances share the same underlying cluster volume means that there is no delay when pulling in blocks from S3.
Finally, Aurora’s other main benefit, as I alluded to, is that its shared cluster volume means that replication lag is typically quite low; 10-30 msec IME. However, also IME, devs don’t design apps around this, and anything other than instantaneous is too slow, so it doesn’t really matter.
Just seeing this now. (Is there a way to turn on notifications here?)
Thanks for the breakdown!
And I suppose they are eating the cost of worse latency to allow for more scalability?
Well, I imagine at least the emotional aspect of this squabble had more than a billion reasons injected via Databricks.
Edelman PR