looks like this would work except the ability for the build.env properties to read github secrets seems to have been deprecated so the only way to do it would be to use a plaintext db string with username/password in the vercel.json file which would be bad. Shot a support request over to vercel to see if they have a solution.

I did find a workaround here that I'm not super happy with but does work: Steps: 1) In Vercel, create a DATABASE_URL env variable pointing to the pooled DB. 2) In Vercel, create a DATABASE_CREDENTIALS env variable only containing the credentials string ex:

username:password

. 3) In Vercel, create a DATABASE_UNPOOLED_URL_FRAGMENT env variable only containing the url fragment for the unpooled url ex:

<http://somehost.com:1234/unpooleddb|somehost.com:1234/unpooleddb>

4) In schema.prisma, point to the DATABASE_URL like so:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

5) In package.json, override the DATABASE_URL env variable with the nonpooled db url during the build steps just before the migration and reference the DATABASE_CREDENTIALS env variable:

"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "vercel-build": "export DATABASE_URL=\"postgresql://$DATABASE_CREDENTIALS@$DATABASE_UNPOOLED_URL_FRAGMENT\" && prisma migrate deploy && next build",
    "prisma:generate": "prisma generate",
    "postinstall": "prisma generate"
  },

6) After build, Vercel automatically re-sets the DATABASE_URL to the pooled string that was set in their UI in step #1 ...this feels pretty hacky but it's the only approach that lets you dynamically change the URL during the build step and avoids needing to create an additional schema that I've been able to find. Also you this lets you define different unpooled URLs for different environments via the normal Vercel env variable UI. Will followup with Vercel's response to my earlier inquiry as well in case they have a better way to do this.

Following up on this thread. Heard back from Vercel and their recommendation is to use a non-pgbouncer URL env variable in the schema.prisma file and then override it in the client instantiation with a pgbouncer URL env variable. It feels a little upside down to me (if you don't have a central/single instantiation of the prisma client you have to remember to override it or you'll hit the wrong db), but I do think it's probably a safer approach since what I reported above isn't exactly a documented/supported method.

@John Egan sorry to @ you but probably you didn't see my reply 🙂