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.

Comments URL: https://news.ycombinator.com/item?id=45379857

Points: 7

# Comments: 3

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

Comments URL: https://news.ycombinator.com/item?id=44388895

Points: 2

# Comments: 0

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

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

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.

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.

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.

https://neon.tech/blog/postgres-17

(note that not all extensions are available yet, that takes some time still)

SELECT random(1, 10) AS random_number;

Comments URL: https://news.ycombinator.com/item?id=41181165

Points: 12

# Comments: 3

> Current CI/CD practices often make it very easy for software developers to commit and roll out database migrations to a production environment, only to find themselves in the middle of a production incident minutes later. While a staging deployment might help, it's not guaranteed to share the same characteristics as production (either due to the level of load or monetary constraints).

(neon.tech employee here)

This is where branching databases with production data helps quite a bit. Your CI/CD environment and even staging can experience the schema changes. When you build from a seed database you can often miss this kind of issue because it lacks the characteristics of your production environment.

But the author rightly calls out how staging isn't even enough in the next paragraph:

>The problem is, therefore (and I will repeat myself), the scale of the amount of data being modified, overall congestion of the system, I/O capacity, and the target table's importance in the application design.

Your staging, even when branched from production, won't have the same load patterns as your production database. And that load and locks associated will result in a different rollout.

This has me thinking if you can match the production environment patterns in staging by setting staging up to mirror the query patterns of production. Mirroring like what's available from pg_cat could put your staging under similar pressure.

And then this also made me think about how we're not capturing the timing of these schema changes. Unless a developer looks and sees that their schema change took 56 seconds to complete in their CI system you won't know that this change might have larger knock on effects in production.

Comments URL: https://news.ycombinator.com/item?id=40286403

Points: 98

# Comments: 29

hey all, i've only been with neon for a very short time but i'm super excited to be here because i believe neon can deliver an amazing developer experience that databases have been lacking. while we are simply postgres on top the neon platform is something special that unlocks a lot of new possibilities.

this ga is simply marking readiness for the platform and the team that has been building it. there's a lot more to do going forward.

as we're looking forward, post-GA, i'd love to hear what you think neon needs to focus on next. here's what i'm seeing so far: - improved gh actions integration - more extensions - better developer extension support - autoscaling communications - metrics / logs integrations

what else?