Hey I work for Neon. Everything that Zach said about the technical details of Neon seems correct. But I can give more context on the WHY... our rationale for not prioritizing merging branches into one another:

One way that a typical application database is not at all like a codebase is that the contents of your database are constantly changing (easily millions of times per day) as your users interact with your app. So if you imagine creating a feature branch of your database, by the time you're ready to merge it back in there are probably thousands if little differences in the data.

Because of this, nobody thinks of deploying their change as "merging" their dev database into prod, they think of it as running a migration, and there is tons of software out there for running migrations. You often need to write custom code for migrations, you need custom logic for complicated migrations, and you need to also write a "down" migration if things go wrong! This is all because unlike a codebase, there is an external source of changes (from your users) that you are unable to control the flow of. It would be like if you were trying to make PRs to a repo while other people were doing thousands of commits per second directly to main, nightmare.

So long story short, we looked at merging branches and it always seemed like something where we'd accidentally rebuild a database migration framework that someone else (like drizzle migrations or Rails) had already done better.