clarkbw

Neon has pg18 ready to use on the day it's released, just like last year.

Sadly one of the most interesting features, Async I/O, is going to take some work at the file system level for us to support. For now all operations are still sync. And we'll keep updating on our progress there.

I think this was actually trying to say, Neon prices were high. Because otherwise I agree it doesn't make sense.

And Neon will be lowering prices dramatically... a day from now?

cold starts are 500ms on average, and that's only for the first call that wakes up the db from hibernation. people still seem to think that this latency happens for every call (see other threads here) but once the service has woken up (cold start over) you're back to regular (sub 10ms) latency timings and the service continues to run that way. you'll only hit a cold start again if (you have this option turned on) your service goes idle for > 5 min. You can turn scale-to-zero off and you'll run 24/7, have zero cold starts.

$19 plan is going away, will launch a better $5 plan soon.

It is!

And we plan to have 18 out as quickly as we did 17; on the day of release.

is it only the auth that's a problem? you could try stack auth or other oss auth providers out there.

(neon employee)

there isn't something like Vitess for Postgres yet but there needs to be. Migrations are painful in general and they become very painful at scale. i haven't used gel yet, i know it manages migrations but i don't know to what extent. most of my experience is with prisma, drizzle, and atlas.

neon is working on some plans to solve migrations at scale. we think our custom storage layer will allow us to optimize certain paths, like setting a default value in a new column for a table with millions of rows. this alter command can take a lock on a table for hours. but ultimately we need better tooling.

ideally there is a client and a hosted service such that you can use the client to run migrations on your own from the CLI and integrate it into your dev workflow. the hosted service version allows you to push up your schema change from the client to an API. from there you can manage the migration rollout from an operational dashboard that helps you tune resourcing.

when i was at github we used vitess to roll out a migration that took 3 weeks to complete. a long time to wait but that's a better tradeoff compared to a migration that takes down production for 6 hours.

(neon employee)

we have multi-region disaster recovery and replicas coming in 2025. Switch over time will be greater than this active-active system but the overall latency for Neon should be much less on a consistent basis.

oh, i see I'm getting downvoted; this isn't a sales pitch for my "managed postgres platform".

every year a new postgres release occurs and i want to try out some of the features i have to find a way to get it. usually nobody has it available.

here's the list of homebrew options I see right now:

brew formulae | grep postgresql@ postgresql@10 postgresql@11 postgresql@12 postgresql@13 postgresql@14 postgresql@15 postgresql@16

maybe you're seeing otherwise but i updated a min ago and 17 isn't there yet. even searching for 'postgres' on homebrew doesn't reveal any options for 17. i don't know where you've found those but it doesn't seem easily available.

and i'm not suggesting you use a cloud service as an alternative to homebrew or local development. neon is pure postgres, the local service is the same as whats in the cloud. but right now there isn't an easy local version and i wanted everyone else to be able to try it quickly.

Some awesome quality-of-life improvements here as well. The random function now takes min, max parameters

SELECT random(1, 10) AS random_number;