# Best Secrets Manager for Database Credentials in 2026: Vault vs Infisical vs Doppler

> Comparing HashiCorp Vault, Infisical, Doppler, and 1Password, the vendor-neutral options for database credentials that work across clouds and on-prem.

Tianzhou | 2026-07-31 | Source: https://www.bytebase.com/blog/best-secrets-manager-for-database-credentials/

---

Storing a database password is table stakes, every tool here does it. What differs is whether it gives you short-lived, auto-rotated credentials instead of one password that lives forever.

If you're all-in on one cloud, the native manager, [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/), [GCP Secret Manager](https://cloud.google.com/security/products/secret-manager), or [Azure Key Vault](https://azure.microsoft.com/en-us/products/key-vault), is the path of least resistance: deep IAM integration and less to run, in exchange for making that cloud harder to leave. AWS's rotation templates are the most automated of the three, GCP gives you the least, but the trade is the same everywhere: convenient right up until your database or your compute needs to live somewhere else. That trade isn't this post.

This is about the vendor-neutral options, the ones that work the same way whether your database sits in AWS, GCP, on-prem, or across all three at once. We compared the four tools that actually compete for that job:

- Dynamic secrets pioneer, best with Terraform - [HashiCorp Vault](#hashicorp-vault)
- Open-source Vault alternative - [Infisical](#infisical)
- Rotation as the whole product - [Doppler](#doppler)
- A password manager extending into service secrets - [1Password](#1password)

## HashiCorp Vault

[Vault](https://www.vaultproject.io/)'s core trick is dynamic secrets: ask it for database access and it creates a real Postgres or MySQL user on the spot, hands you the password, and drops the user automatically when the lease expires. Nothing to rotate, because nothing sticks around long enough to need it.

What makes Vault the default in platform-engineering shops is the Terraform provider. The same `terraform apply` that provisions the database can declare the Vault database secrets engine, the role, and the TTL in the same run, so credential issuance becomes part of the infrastructure pipeline instead of a manual step somebody does afterward. I first ran into Vault at PGConf Silicon Valley in 2016, and it was the Terraform integration, not the secret storage, that hooked me.

Self-hosting means operating it yourself: your own HA setup, unseal process, and upgrade cadence. HCP Vault Dedicated hands that operational load to HashiCorp instead, if you'd rather not run it.

## Infisical

[Infisical](https://infisical.com/) is what Vault would look like if a small team built it with weekend-project ergonomics: a clean web UI, straightforward SDKs, and a free self-hosted edition with no artificial usage caps. For teams that want Vault's self-hosting story without Vault's operational weight, it's a real alternative.

Dynamic database secrets, the ephemeral per-request credential that's Vault's whole reason for being, are newer in Infisical and cover fewer database engines. If all you need is a single well-organized place to store and rotate static credentials, that gap doesn't matter. If you specifically need Vault-style ephemeral Postgres users today, check the engine list before assuming Infisical already does it.

## Doppler

[Doppler](https://www.doppler.com/) treats rotation as the product, not a feature bolted on later. Rotated Secrets keeps two credentials alive at once, an active one and a standby, so the swap to a freshly rotated password never has a moment where every connection is using the old one. For databases sitting behind a VPC with no public endpoint, a proxied rotation agent runs inside your network and does the rotation without opening anything to the internet.

The catch is that Doppler itself is hosted only. There's no self-hosted Doppler the way there's a self-hosted Vault or Infisical. If keeping secrets infrastructure entirely inside your own network is a hard requirement, that rules Doppler out regardless of how good the rotation story is.

## 1Password

[1Password](https://1password.com/developers/secrets-management) built Secrets Automation on top of a password manager, and that lineage shows. Its strength is unifying the human side, the passwords your team already stores in 1Password, with programmatic access for scripts and CI. What it doesn't have is Vault's ephemeral, TTL-based database user generation; secrets get stored and rotated, but nothing is created fresh per request and dropped afterward. If your team already lives in 1Password for personal credentials, extending that to service secrets is convenient.

## Test case: application access

A new service instance starts up. No human is involved, it just needs a Postgres credential, on every restart, at whatever scale the fleet runs at.

**HashiCorp Vault**: the app authenticates (AppRole, Kubernetes service account) and asks the database secrets engine for a lease. Vault mints a brand-new Postgres user for that specific request. Two instances of the same service get two different database users. The Vault Agent injector handles this in Kubernetes without a code change: the sidecar authenticates, fetches the lease, and writes it to a file the app reads.

**Infisical**: the same shape as Vault. A machine identity authenticates via Universal Auth or Kubernetes auth and requests a dynamic secret, getting a unique database user per request, delivered by SDK, API, or the Kubernetes operator syncing straight into a Kubernetes Secret.

**Doppler** also does the basic job well: the app fetches the current value through the CLI or SDK, authenticated with a Service Token scoped to one project, environment, and config. That token is tightly scoped; the value behind it isn't. It's the same Rotated Secret every instance with that token reads, updated on Doppler's schedule, not minted per request.

**1Password** covers the basic job too: the app reads the stored item through a Connect server or a Service Account token scoped to a vault. Still one credential, shared by every instance with access to that vault. The exception is 1Password's Credential Broker, which as of 2026 issues a distinct credential per GitHub Actions workflow run, real per-run scoping, but so far only for that CI/CD case, not general app-to-database delivery.

Vault and Infisical mint a unique database user per request by default. Doppler and 1Password still hand every instance with access the same shared credential, though 1Password's Credential Broker is a first step toward per-run scoping in CI/CD.

| Tool | Basic fulfillment | Per-instance credential | Why |
| --- | --- | --- | --- |
| HashiCorp Vault | ✅ Yes | ✅ Yes | Database secrets engine mints a unique lease per request |
| Infisical | ✅ Yes | ✅ Yes | Dynamic secrets mint a unique credential per request |
| Doppler | ✅ Yes | ❌ No | Service Tokens are tightly scoped, but the value behind one is shared by every instance using it |
| 1Password | ✅ Yes | ⚠️ Partially | Vault-scoped items are shared; Credential Broker issues per-run credentials, but only for GitHub Actions so far |

## Test case: human access

A production incident is running. The on-call engineer doesn't have standing access to the database, that's the policy, and pulling the shared prod password out of a vault defeats the reason it's not a shared password anymore. What actually happens when someone needs a few minutes of real access to a database they don't normally touch?

**HashiCorp Vault** has the closest native answer: Control Groups. The engineer requests the database credential, Vault wraps the response instead of returning it, and holds it until the required number of approvers sign off, say one manager and one from security. Only then does Vault unwrap the ephemeral Postgres user and hand it over. It's a real approval gate, built directly into Vault's model of who gets to unwrap a secret, not a workaround bolted on top.

**Infisical** ships the same idea as Access Requests: multi-step approval chains, group approvers, auto-expiring grants once approved. It's a genuinely built-for-this feature, not a bolt-on.

**Doppler** doesn't have this. Change Requests are peer review for editing a secret's value, not a workflow for granting someone temporary read access to one. The closest it gets is issuing a machine identity a scoped secret over OIDC, which solves a CI/CD problem, not a human at a keyboard at 2am.

**1Password** actually answers a version of this well, just not the version with an audit trail. Anyone holding the item can generate a link that expires in an hour or after a single view and hand it straight to the engineer. It's fast and needs no infrastructure. It's also still the same standing password, handed to a second person, with no approval step and no record of what they did with it once they had it.

Even where an approval workflow exists, it stops at handing over a credential. What happens afterward, which tables it touched, whether a masked column got read, isn't covered by any of them.

| Tool                | Fit          | Why                                                                                                                |
| ------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------ |
| HashiCorp Vault     | ✅ Yes       | Control Groups hold the credential until the required approvers sign off                                           |
| Infisical           | ✅ Yes       | Access Requests: a multi-step approval chain with an auto-expiring grant                                           |
| Doppler             | ❌ No        | Change Requests review edits to a secret's value, not a grant of temporary access                                  |
| 1Password           | ⚠️ Partially | An expiring share link gets access out fast, but it's the same standing password, no approval step, no audit trail |

## The verdict

Pick based on what's already true about your infrastructure:

- Running infra as Terraform -> **Vault**.
- Want Vault's model of dynamic secrets and access requests without Vault's ops burden -> **Infisical**.
- Want rotation handled for you with zero downtime and no server to run -> **Doppler**.
- Already standardized on 1Password for human passwords and want that same store to cover service secrets too -> **1Password**.

Even the two that pass both test cases, Vault and Infisical, stop at the same place: once the lease is issued or the access request approved, neither one follows the credential into the database. What happens next, which tables got touched, whether a masked column got read, isn't covered by any of the four. [Bytebase](/) picks up from there, on top of whichever vault you already use, so the audit trail covers the queries a human or an agent actually runs, not just the moment they got a password.

![jit-workflow](/content/blog/best-secrets-manager-for-database-credentials/jit-workflow.svg)

## Related reading

- [Database Credentials Management: Best Practices](https://www.bytebase.com/blog/database-credentials-management-best-practices/)