Hi, I’m facing an error in production where all database write operations fail due to a read-only connection being in the connection pool:
I believe this connection was created by a developer using a database client like dbeaver and connecting to the connection pooler (pgbouncer) using “read only” mode. After that the connection stayed in the pool and is completely breaking the application.
While researching this issue I came across this issue in the pgbouncer repository where someone mentions that restarting pgbouncer or running a “DISCARD ALL” command that can be done to reset the session status:
Does anyone know if this can be done with the pgbouncer instance provided by vercel? I would appreciate any help since this is completely breaking the application in production.
Hey @giovanioliani. I don’t know the answer to this one and don’t want to lead you astray. I reached out to our storage team for advice and we’ll keep you updated.
Yes, we are using Vercel’s Postgre solution (connetion string is something like “postgres://default:PcM4eLXXXXXX@ep-twiXXXXt-XXXX-29XXXXXX-pooler.us-east-1.postgres.vercel-storage.com/verceldb?pgbouncer=true&connect_timeout=15”).
On the application we connect to it only using Prisma ORM (@prisma/client": "^5.17.0).
I made sure to turn off my “read only” toggle for connecting with outside tools like Dbeaver and to not connect to the database using the connection pooler URL and it stopped happening, so I’m sure that was causing the issue. My theory is that after creating a “read only” connection through the pooler, the connection was reused by other pool users (like Prisma’s client).
It’s kind of wild that a read operation on the database could break the entire application in production, but it is what it is.
