9 ms·

What 'Project Hail Mary' teaches us about the PlanetScale vs. Neon debate

71 points by konsalexee 1y ago

chubot 1y ago
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?
- sinnickal 1y ago
  Edelman PR
- konsalexee 1y ago
  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.
  - twoodfin 1y ago
    Well, I imagine at least the emotional aspect of this squabble had more than a billion reasons injected via Databricks.
  - sgarland 1y ago
    > 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.
    - vendiddy 1y ago
      Why is it an awful idea? I don't understand the trade-offs well.
      - sgarland 1y ago
        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.
- PhilippGille 1y ago
  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.
  - lukasb 1y ago
    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.
  - ghiculescu 1y ago
    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?
    - deleted 1y ago
      [deleted]
    - ksec 1y ago
      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 https://planetscale.com/blog/planetscale-vs-amazon-rds
- sgarland 1y ago
  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-because-mistakes-happen https://neon.com/blog/oops-proof-your-vibe-code-with-neon-be... [1]: https://x.com/isamlambert/status/1935333197635588393 https://x.com/isamlambert/status/1935333197635588393
crims0n 1y ago
Tangentially related, is this book worth the hype? I don't read a lot of genre fiction, but don't like to miss out on the exceptional (just finished and loved Flowers for Algernon, as an example). Edit: Sounds like an enjoyable, low commitment book. Will give it a try, thanks for the feedback.
- ecshafer 1y ago
  No. Any Weir anything is not going to break into the tier of exceptional. Its YA fiction level writing with a bit of science sprinkled in.
- loteck 1y ago
  Almost nothing is worth the hype but the book is an enjoyable page turner if you like space adventures and speculative science. Audiobook also got some extra attention, I'd go with that if you like audiobooks.
  - GolfPopper 1y ago
    This. It was fun and very readable, but not something I have any desire to go back and read again.
  - GiorgioG 1y ago
    I loved the Audiobook.
    - anonymars 1y ago
      I would almost say you should try to listen to the audiobook instead of reading it, as a unique experience
      - joshgachnang 1y ago
        I haven't read the book, but I imagine the music notes wouldn't land the same way in written form.
- 1y ago
bitbasher 1y ago
I don’t get it. Sending a query to a remote server is going to be much slower than sending the query to local database. When has Postgres not been enough on its own?
- abroadwin 1y ago
  For me it's all about the branching Neon provides. Being able to instantly and automatically have a branch of my production data for every dev branch is incredibly useful.
  - throwaway7783 1y ago
    Aren't there data security concerns with this?
    - Sayrus 1y ago
      You can have an anonymized dump like you'd normally do and then branch it. This allows spinning up environments in seconds and without the disk footprint of a new replica or dedicated DB. The privacy / security constraints stay the same whether you are branching or not.
      - throwaway7783 1y ago
        That is true. Anonymizing data is the biggest part of such a workflow. Most prevalent use case that requires production data is for debugging. I guess there is some value in branching non-prod databases for feature development. Most security teams do not allow prod data in non prod environments, anonymized or not l.
akulkarni 1y ago
I agree with the overall sentiment of this post. I’ve learned (sometimes the hard way!) that every design choice comes with real trade-offs. There’s no magic database architecture that optimizes every dimension (e.g., scalability, performance, ease-of-use) simultaneously. Social media often pushes us into oversimplified "winner vs. loser" narratives, but this hides the actual complexity of building great infrastructure. Recognizing and respecting these differences makes us smarter engineers, better community members, and frankly, just more enjoyable people to chat with. PS Thank you for helping me add a new book to my list :-)
mrcwinn 1y ago
tldr; Supabase. XD
patrickhogan1 1y ago
The discussion centers on speed and scalability. I recently used Neon in a project mainly because it was easy to setup.
- grrowl 1y ago
  Easy to setup and instant forks for devs was it for me. Felt the pain with dev app state in the past and this took <20 minutes to migrate (beta users only) and go live, and get back to feature work.

71 points by konsalexee 1y ago

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?

sinnickal 1y ago
Edelman PR
konsalexee 1y ago
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.
- twoodfin 1y ago
  Well, I imagine at least the emotional aspect of this squabble had more than a billion reasons injected via Databricks.
- sgarland 1y ago
  > 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.
  - vendiddy 1y ago
    Why is it an awful idea? I don't understand the trade-offs well.
    - sgarland 1y ago
      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.
PhilippGille 1y ago
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.
- lukasb 1y ago
  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.
- ghiculescu 1y ago
  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?
  - deleted 1y ago
    [deleted]
  - ksec 1y ago
    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 https://planetscale.com/blog/planetscale-vs-amazon-rds
sgarland 1y ago
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-because-mistakes-happen https://neon.com/blog/oops-proof-your-vibe-code-with-neon-be... [1]: https://x.com/isamlambert/status/1935333197635588393 https://x.com/isamlambert/status/1935333197635588393

crims0n 1y ago

Tangentially related, is this book worth the hype? I don't read a lot of genre fiction, but don't like to miss out on the exceptional (just finished and loved Flowers for Algernon, as an example). Edit: Sounds like an enjoyable, low commitment book. Will give it a try, thanks for the feedback.

ecshafer 1y ago
No. Any Weir anything is not going to break into the tier of exceptional. Its YA fiction level writing with a bit of science sprinkled in.
loteck 1y ago
Almost nothing is worth the hype but the book is an enjoyable page turner if you like space adventures and speculative science. Audiobook also got some extra attention, I'd go with that if you like audiobooks.
- GolfPopper 1y ago
  This. It was fun and very readable, but not something I have any desire to go back and read again.
- GiorgioG 1y ago
  I loved the Audiobook.
  - anonymars 1y ago
    I would almost say you should try to listen to the audiobook instead of reading it, as a unique experience
    - joshgachnang 1y ago
      I haven't read the book, but I imagine the music notes wouldn't land the same way in written form.
1y ago

bitbasher 1y ago

I don’t get it. Sending a query to a remote server is going to be much slower than sending the query to local database. When has Postgres not been enough on its own?

abroadwin 1y ago
For me it's all about the branching Neon provides. Being able to instantly and automatically have a branch of my production data for every dev branch is incredibly useful.
- throwaway7783 1y ago
  Aren't there data security concerns with this?
  - Sayrus 1y ago
    You can have an anonymized dump like you'd normally do and then branch it. This allows spinning up environments in seconds and without the disk footprint of a new replica or dedicated DB. The privacy / security constraints stay the same whether you are branching or not.
    - throwaway7783 1y ago
      That is true. Anonymizing data is the biggest part of such a workflow. Most prevalent use case that requires production data is for debugging. I guess there is some value in branching non-prod databases for feature development. Most security teams do not allow prod data in non prod environments, anonymized or not l.

akulkarni 1y ago

I agree with the overall sentiment of this post. I’ve learned (sometimes the hard way!) that every design choice comes with real trade-offs. There’s no magic database architecture that optimizes every dimension (e.g., scalability, performance, ease-of-use) simultaneously. Social media often pushes us into oversimplified "winner vs. loser" narratives, but this hides the actual complexity of building great infrastructure. Recognizing and respecting these differences makes us smarter engineers, better community members, and frankly, just more enjoyable people to chat with. PS Thank you for helping me add a new book to my list :-)

mrcwinn 1y ago

tldr; Supabase. XD

patrickhogan1 1y ago

The discussion centers on speed and scalability. I recently used Neon in a project mainly because it was easy to setup.

grrowl 1y ago
Easy to setup and instant forks for devs was it for me. Felt the pain with dev app state in the past and this took <20 minutes to migrate (beta users only) and go live, and get back to feature work.