What is the difference between Vault performance replication and DR replication?

Think of a retail bank with branch offices. Performance replication is like having local tellers at each branch who can check your account balance (reads) but must call headquarters to process a transfer (writes). Disaster recovery replication is like keeping a fully stocked backup headquarters that sits idle until the main office goes down, at which point it takes over everything.

Vault replication exists because a single Vault cluster in one region creates two problems: applications in distant regions experience high latency on every secret read, and a regional outage kills all secret access. Vault Enterprise offers two replication modes that address these separately, because the solutions need different architectural tradeoffs.

Performance replication continuously streams encrypted data from the primary cluster to secondary clusters. Each secondary has a complete copy of the secrets, policies, auth methods, and token state from the primary. Secondaries serve read requests locally with low latency: a service in eu-west reading a KV secret hits the local secondary instead of crossing the Atlantic to us-east. Write requests (creating secrets, changing policies, generating dynamic credentials) get forwarded to the primary transparently. The secondary handles the client connection while the primary runs the write, and the result comes back to the client. This is invisible to the application. Performance secondaries also maintain their own token store and can authenticate clients locally.

Disaster recovery replication also streams data from the primary, but the DR secondary does not serve any client traffic at all. It keeps a warm copy of everything, including local-only data like auth mounts and tokens. When the primary becomes unavailable, an operator promotes the DR secondary to primary using the DR promotion API. After promotion, the former secondary becomes the new primary and starts handling traffic. The RPO (how much data you could lose) depends on replication lag, and the RTO (how long until you are back up) depends on how fast you can promote and update DNS or load balancers.

The gotcha that trips up many architects is thinking one type covers both needs. Performance secondaries cannot generate dynamic secrets when the primary is down because dynamic secret creation is a write that forwards to the primary. If teams depend on dynamic database credentials from a performance secondary and the primary fails, all new credential requests fail even though existing leases may still work. DR secondaries require a promotion event, meaning secret access is unavailable during the promotion window. Architects who need both low latency and continuity must deploy both: performance secondaries in each active region for fast reads, plus a DR secondary in a separate failure domain for business continuity.