Bug with Postgres integration

Current versus Expected Behavior:

  • Expected: After resetting my database credentials, I expected to be able to reconnect my database or update my environment variables accordingly.
  • Current: My database got disconnected from the project without removing the associated environment variables. These variables are now locked to the disconnected database and cannot be removed. Attempts to reconnect the database fail because the variable names are already in use.

Issue Summary: After resetting my database credentials, my database disconnected from the project. However, the environment variables weren’t removed, and now they’re locked, marked as connected to a database that no longer exists in my project. Attempting to reconnect the database fails due to these variable names being in use. This has taken down my production site, forcing me to rename all variables in my codebase to restore functionality.

As I’m on a hobby plan, I couldn’t reach support directly, which left me unable to resolve this critical issue in a timely manner. I am concerned about the lack of control and support available, which may affect my decision to continue using your service or consider a paid plan in the future.

Could someone please help resolve this bug?


  1. Reset database credentials
  2. Database disconnects, but environment variables remain locked and unusable
  3. Attempt to reconnect database, but variable names are marked as already in use

Hi @theodortomas. It sounds like you’re using Vercel Postgres, but please let me know if you’re using a different provider. Can you walk me through the steps you took to reset database credentials?

Hello,

Yes, I am using Vercel’s Postgres integration. While I don’t recall each step precisely, I can give a general overview of what I did. I started by going into my Postgres settings and selecting the “reset credentials” option. I noticed that I needed to redeploy my project to apply the new credentials, so I proceeded with that, assuming the database might be temporarily inaccessible until the redeployment was complete.

I may have had an old tab open with the environment variables page, which could have affected the changes. Currently, I’m unable to use the default environment variable names, nor can I delete the old variables. Although I’ve already changed the variable names to keep things running due to the response delay, I would still like this issue resolved so that I can revert to the default names, which are preferred for my product’s setup. Could you please assist with this while your team addresses the bug on your end?

Also, could you clarify whether the reset process results in a temporary break in my app’s access to the database, or are there safeguards in place to maintain connectivity during the rebuild and redeploy process?

Thank you!

Thanks for your patience. When you reset the credentials for the Postgres database, environment variables are automatically updated for connected project(s). You do not need to manually edit the environment variables. In fact, you will not have the option to edit or delete those variables because they are managed for you by the Postgres integration.

It is expected that there would be a period of downtime until you redeploy or create a new deployment. This is noted in a warning as part of the credential reset process. The new variables are used during the deployment and connection is restored when it succeeds.

It’s like if you were sharing a streaming account with your friend and reset the password without telling them. When they try to log in using the old password (i.e. the credentials on the existing deployment), they see some form of “access denied” error. Then you let them know the new password (i.e. redeploy with the new credentials) and they are able to log in again.

Thanks for the explanation. I wanted to know for sure.

How long can I expect it to take to remove the Env Vars using the default names, i.e. POSTGRES_URL, POSTGRES_DATABASE and so forth? I am unable to delete them from my project due to them being locked so I had to resort to using a new name for these variables(POSTGRESV2_DATABASE, POSTGRESV@_URL… ), however I would like to stick with the default naming.

There should be no need to remove the existing variables. Their values are automatically updated for you when you reset the credentials. All you need to do is redeploy so the project can be rebuilt with the updated values. I hope that makes sense! :slightly_smiling_face:

No there was a bug when I did so and it said that the project was not connected to my database. Then when trying to manually connect it again using the default variable names it said that those keys were in use(even though it didn’t show the forementioned project in the “connected projects” list). So I had to create new variable names suffixed with “V2”, update my project changing what env variables keys were referenced and redeploy everything. I currently now have 2 sets of env variables for my postgres database, but I would like to change it back to not have the V2 suffix. Please could you have someone from your techincal team look at this and manually delete the old, not in use variables because I am unable to do so. On the “environment” screen it says the variables are in use but on the database screen it says it is not. There is a bug here.

Can you share the name of the project that exhibits the problem?

The projectid where I am having this problem is prj_hfaZLEvfkSnsYbk6bMufa0AVeJP8

Thanks for your help!

Thanks for sharing that. I’ve sent your report to the storage devs. While we wait for someone on that team to be available to help, I have one more idea to try.

You might be able to remove the old environment variables using the CLI. First log in with vercel login and link to your local project with vercel link. Then, you should then be able to list the environment variables with vercel env ls. From there you can use vercel env rm to select which environment variable to remove.

If you give it a try, please let me know whether or not it works. I’ll keep you updated on what I hear from the team either way.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.