> Rotation, what it breaks, and what to do when a string gets away from you. # Replacing the password In the studio: **Database** → **Replace password**. The role gets a new password, and with it a new connection string. Both the pooled and direct strings change; the host, database and role stay the same. ## There is no grace period The old string stops working the moment the new one exists. Anything still using it gets `password authentication failed` on its next connection — not at its next deploy, at its next connection. That is Postgres's model rather than a choice of ours: a role has one password, and setting a new one replaces it. There is no version of this where both work for an hour. So the order that works is: 1. Replace the password in the studio. 2. Copy the new string, or fetch it with [`GET /v1/data/_connection`](/docs/data-api/connection-details). 3. Update your secret store and redeploy. Between 1 and 3 your application cannot connect. If that window matters, do it during a deploy rather than in the middle of the afternoon. ## When to do it - A string was pasted somewhere it should not have been — a chat, a ticket, a screenshot, a log. - Somebody with access to it has left. - On a schedule, if your compliance regime says so. Nothing here expires on its own. ## What it does not do Rotation does not touch your data, your schema, your tables or the role's permissions. It is one password being replaced. Connections already open are not killed; they simply cannot be re-established with the old credential. ## If you lose it entirely Nothing is lost. The connection string is stored on our side — that is why the studio can show it to you again — so "I no longer have it" is a page reload rather than a recovery. That is also precisely why rotation exists, and why the studio hides the value behind a **Show** button rather than printing it to anybody who opens the page.