How to Rotate Database Credentials Safely Without Downtime
DataDike Security Research
PAM Research & Field Engineering
A standing database password that has not changed in three years is one of the easiest credentials for an attacker to enumerate, and yet the typical reason it has not changed is that nobody is brave enough to rotate it. Every application that connects to that database has the password baked into a config file, a Kubernetes secret, an old runbook, or — in the worst cases — the source code. Rotate it naively and production goes down.
The four rotation patterns, ranked
There are four ways to rotate a database credential, and they differ in how much trust your apps place in the vault. Pick the lowest-trust pattern your app will tolerate.
Pattern 1: Dual-credential rotation (low integration, high safety)
Maintain two credentials per database role — primary and shadow. At each rotation interval, change the shadow, swap it to primary, then revoke the old primary after a grace window. Apps that read the new password from the vault at startup pick it up on the next bounce; apps that hold long-lived connections never see disruption because the old credential remains valid through the grace window.
Pattern 2: Credential injection by the PAM gateway
For human operators connecting to a database via a SQL client, the PAM gateway proxies the connection and injects the credential into the protocol stream. The operator never sees the password. The credential rotates on whatever cadence you choose, and the rotation never breaks anything because no human or app ever held the old value.
This pattern is dominant for DBA access in regulated environments because it solves the audit problem at the same time as the rotation problem.
Pattern 3: Application reads the credential on demand
The application has a vault-aware client library. At connection time it fetches a fresh credential from the vault and uses it for the lifetime of the connection (or a configurable TTL). When the credential expires, the app fetches the new one. This is the cleanest model when you control the application code; it eliminates the dual-credential dance entirely.
Pattern 4: Dynamic credentials minted per session
The vault is itself the credential issuer. For each session it creates a database user that lives for the lifetime of the session and is dropped at the end. There is no password to rotate because there is no long-lived password. This is the gold standard for high-sensitivity systems but requires that the vault have privileged access to the database to create and drop users on demand.
| Pattern | App changes required | Auditability | Operational risk during rotation |
|---|---|---|---|
| Dual-credential | None (apps read vault at startup) | Medium | Low |
| Gateway injection | None for humans; N/A for apps | High | None — apps untouched |
| On-demand fetch | Library swap | High | Low |
| Dynamic credentials | Library swap | Highest | None — credential is ephemeral |
Engine-specific notes
PostgreSQL
Postgres has first-class support for the dual-credential pattern via separate LOGIN roles inheriting from a shared application role. For dynamic credentials, CREATE USER ... VALID UNTIL combined with a privileged rotator account works well; the vault holds the rotator and creates per-session users that expire on a schedule.
MySQL
MySQL's ALTER USER ... PASSWORD EXPIRE INTERVAL clause makes timed expiry trivial. For applications that cannot tolerate even momentary auth failures during the swap, MySQL 8 supports dual-password authentication (PASSWORD HISTORY), letting two passwords be valid simultaneously for a configured window.
SQL Server
SQL Server is the engine that most often holds the credentials you are afraid to rotate, because it commonly authenticates Windows service accounts whose passwords are also held by the OS. The dual-credential pattern works at the OS level rather than at the database level: rotate the Windows account password, distribute the new password to the apps via the vault, and the database picks up the change through Windows integrated auth without any database-side action.
Trap to avoid
Do not enable on-demand rotation against a production database before you have load-tested the rotation under peak connection rates. The acceptance criteria is "zero failed connections during the swap window," not "the average case worked."
Where DataDike fits
DataDike supports all four patterns out of the box for Postgres, MySQL, MariaDB, SQL Server, Oracle, MongoDB, and Redis. For most customers the first wave is gateway injection for DBAs (immediate audit win, zero app changes) and dual-credential for application accounts (manageable, recoverable). Dynamic credentials follow once the team is comfortable with the rotation tempo.
