Great analysis. Thank you. I've been evaluating both (Neon, PlanetScale). I like that Neon is based on Postgres, but really dislike the coldstart times (even as of Nov 2023, seeing at bad as 10 sec). Neon keeps blogging about how they're addressing and are now sub second, but I'm just not seeing it (and running out of Ohio, which is supposedly their best control plane), so this has become trust issue for me. A solution is to just not let the instance suspend, but then quite a bit more expensive and, again, the trust thing. PlanetScale on the other hand just works and performs flawlessly. For these reasons, I'm leaning towards PlanetScale.
Planetscale is a great option indeed! Having used them in production for a while I have nothing but good things to say. Fingers crossed they're able to navigate the current funk with Oracle and grow into a bigger stewardship role for MySQL.
Feature wise both would work for me. I was testing the free tiers tonight and planetscale took about times to return results to me +100ms. Mostly 150ms+) compared to 30-40ms for the other two contenders: neon & cockroachdb. I’m in the Midwest & setup all services in the Midwest. Would you base your decision on that or do u think it might or screwed since it’s the free tier?
I'm not aware of any latency differences by plan for Planetscale. One thing to double-check would be that your region is on AWS if you're using AWS or GCP if on GCP. Crossing data centers could definitely add some lag even in the same region. Not sure if you've seen it but they have some docs on it here: planetscale.com/docs/concepts/network-latency Since the options are functionally equivalent for you, I would next assemble a price curve for each based on some reasonable assumptions and map out how I expected each option to scale over the next couple of years. If that too is a draw, then yeah, latency is a perfectly valid basis to make a decision. Closing thought (which applies to all options) is that you can get pretty far with putting most of your reads behind a short-term Redis cache for really low latency. For a lot of use cases, fast reads and slower writes is perfectly fine.
I am trying to work with cloudflare D1, the sqlite database with drizzle orm. (I'm happy with 500k users with 100k concurrent connections from your prev video). The issue I run into is when you alter the table columns, and the drizzle orm does not handle the migration files for the changes. can you make a video on how you can make adjustments for that change? Or would you suggest pocketbase as better alternative?
Surprisingly enough, I have yet to play with drizzle! But give me more details on your problems and I’m happy to take a look. If you want to use SQLite anyway, pocketbase is indeed a great option.
If you like this video, please consider liking / commenting / subscribing, it helps the channel a lot. Thank you!!
By far the best comparison between the two services I've seen anywhere on the internet. Thank you so much!!
Thank you for such a nice comment!
thanks. to the point without the ads and other bullshit. much appreciated.
My pleasure man. Thanks!
Great analysis. Thank you. I've been evaluating both (Neon, PlanetScale). I like that Neon is based on Postgres, but really dislike the coldstart times (even as of Nov 2023, seeing at bad as 10 sec). Neon keeps blogging about how they're addressing and are now sub second, but I'm just not seeing it (and running out of Ohio, which is supposedly their best control plane), so this has become trust issue for me. A solution is to just not let the instance suspend, but then quite a bit more expensive and, again, the trust thing. PlanetScale on the other hand just works and performs flawlessly. For these reasons, I'm leaning towards PlanetScale.
Planetscale is a great option indeed! Having used them in production for a while I have nothing but good things to say. Fingers crossed they're able to navigate the current funk with Oracle and grow into a bigger stewardship role for MySQL.
Really enjoyed this video! Subscribed.
Thanks, Sam! I'm a huge fan of your work, that means a lot coming from you.
Feature wise both would work for me. I was testing the free tiers tonight and planetscale took about times to return results to me +100ms. Mostly 150ms+) compared to 30-40ms for the other two contenders: neon & cockroachdb. I’m in the Midwest & setup all services in the Midwest. Would you base your decision on that or do u think it might or screwed since it’s the free tier?
I'm not aware of any latency differences by plan for Planetscale. One thing to double-check would be that your region is on AWS if you're using AWS or GCP if on GCP. Crossing data centers could definitely add some lag even in the same region. Not sure if you've seen it but they have some docs on it here: planetscale.com/docs/concepts/network-latency
Since the options are functionally equivalent for you, I would next assemble a price curve for each based on some reasonable assumptions and map out how I expected each option to scale over the next couple of years. If that too is a draw, then yeah, latency is a perfectly valid basis to make a decision.
Closing thought (which applies to all options) is that you can get pretty far with putting most of your reads behind a short-term Redis cache for really low latency. For a lot of use cases, fast reads and slower writes is perfectly fine.
I am trying to work with cloudflare D1, the sqlite database with drizzle orm. (I'm happy with 500k users with 100k concurrent connections from your prev video).
The issue I run into is when you alter the table columns, and the drizzle orm does not handle the migration files for the changes. can you make a video on how you can make adjustments for that change?
Or would you suggest pocketbase as better alternative?
Surprisingly enough, I have yet to play with drizzle! But give me more details on your problems and I’m happy to take a look.
If you want to use SQLite anyway, pocketbase is indeed a great option.