Hacker News Reader

Comment by teaearlgraycold | Hacker News Reader

I looked into serverless postgres offerings a few months ago and came to realize that while it is possible, it doesn't appear that we have figured out how to develop with it as well as we have with traditional postgres. ORMs are fairly incompatible with serverless postgres, and schema migrations are difficult to handle because you have an unknown number of asynchronously updated copies of your code spread around the world. Definitely something you can account for with good planning, but probably not worth the headache to the small and medium-sized teams that would want to sign up for Vercel.

View on HN

I had the same experience. I have a Next.js app and Postgres DB I host on a server-ful PaaS. I hosted the same app on Vercel with Neon DB and the app was significantly slower. The first time Neon is connected, it will be slow so I was prepared for that. Consequent reloads and using the app normally was slow too. Maybe integrating Neon directly with Vercel will fix these issues.

I just don’t see the value prop to use Vercel for SaaS apps. Using a running server for those works better, cheaper, and faster. For consumer-facing storefronts, Vercel is a no-brainer though.

Have you two seen this?

https://github.com/neondatabase/serverless

I used Neon’s cloud DB service directly

That's one thing I don't understand about all this serverless + serverless stuff. Aren't we adding network calls (into different subnets) and cold starts everywhere? That sounds terrible from a performance point of view.

This is why at Xata we have developed our own ORM-like SDK for TypeScript and we store migration files in the repo. The SDK is very lightweight so it runs in any serverless runtime. It also means we can create DB branches on the fly for each PR, with whatever schema is in the repo, and when the PR is merged, the `main` branch gets migrated automatically.

I don't quite follow, but I totally believe that solutions to these problems can be made and maybe your solution really does work well. The issue is that solutions here are not standard yet and thus there will not be much collective knowledge to draw upon. I'd much rather ask engineers to fix age-old RDBMS issues than novel ones that are unsearchable with solutions whose repercussions are not yet known.

There's also issues with complexity even if the solutions get figured out. What are you getting in return? Serverless is great IMO when it's the simplest solution to a problem, ex: "I only have a front end but I really need a simple API action that daisy-chains a few API calls".

> The issue is that solutions here are not standard yet and thus there will not be much collective knowledge to draw upon. I'd much rather ask engineers to fix age-old RDBMS issues than novel ones that are unsearchable with solutions whose repercussions are not yet known.

I definitely understand this. One step at a time, but I think we can move incrementally to a workflow that is much better that what we have today, especially around the DB schema migrations. There's also no reason for this to not work for RDBMS, in fact we're based on Postgres ourselves.

Hey, someone’s got to pave the way!

Reply on news.ycombinator.com