Issue with limit of connection pools when building big static generated app

[seloElo]

Summary

Hi all,

I have been on this this whole afternoon. I have an app using Prisma and postgre, with tons of pages created at built time with data fetched from various queries.

My database limit the number of connection, let's say I have a pool size of 15.
Every time I try to build my app, I reach that size and some pages fails to generate.

The build time looks stateless so I can't control the instances of Prisma being used, and even if I try to reduce the connection limit, looks like Next will try to create more and more "threads" to generate the pages if I limit the number of connection per instance of Prisma which makes me reach the limit again.

Is there any configuration or documentation that I missed on how I could control the build time of my ssg pages to avoid reaching that limit and force the build to wait until some connections are free again? Like a max concurrency for static generation or something?

I saw staticGenerationMaxConcurrency on version 15c, I'm not even sure this might help me fix this but it's not available on v14.

Thanks! Anything would help

Additional information

No response

Example

No response

[canastro]

I'm having the exact same issue. Have you found any fix @seloElo ?

[seloElo]

Version 15 propose new experimental config: https://nextjs.org/blog/next-15#advanced-static-generation-control-experimental

Haven't tried, I ended up self hosting my database (I was on Supabase, limits were too small for a website with 8000 page to build)

[ahammednibras8]

You’re hitting the normal Prisma + Next.js SSG limitation:
Next.js spawns multiple parallel workers during build, and each worker creates its own Prisma connection.
So even with a global Prisma singleton, you still exceed your PostgreSQL pool size.

There is no concurrency control in Next.js 14.
You can’t make SSG “wait” for free connections.

The only reliable solutions are:

1. Upgrade to Next.js 15 and set:
   export const staticGenerationMaxConcurrency = 1;
   This is the official fix.

2. Or avoid connecting to the database during build
   (e.g., prefetch data into JSON or use a caching layer so SSG doesn’t touch the DB).

Everything else — reducing pool size, using singleton, disconnecting manually — won’t solve the root issue because the build runs across multiple processes.