Skip to content
Latchkey

What Is a Database Replica? A Copy That Shares the Load

A database replica is a copy of a database kept in sync with a primary, used to serve reads and to fail over if the primary goes down.

Most databases see far more reads than writes. A replica copies the data from a primary so read traffic can be spread across replicas while writes still go to the primary. Replicas also provide a standby for failover. The catch is replication lag: a replica may be slightly behind the primary at any moment.

How replication works

Writes go to the primary, which streams its changes to one or more replicas that apply them. Reads can be served from a replica to offload the primary. The replica is read-only as far as application writes go.

Why teams use replicas

  • Read scaling: spread read traffic across replicas.
  • High availability: promote a replica if the primary fails.
  • Geographic locality: place replicas near users.
  • Isolating heavy analytical reads from the write path.

Replication lag

A replica is usually a moment behind the primary. Read your own write from a replica too soon and you may not see it yet. This is eventual consistency in concrete form, and it is a frequent source of confusing, intermittent behavior.

The testing pitfall

Code that writes to the primary then reads from a replica can pass locally (one database) and fail in production (split read/write). Tests that mirror the real topology, or that account for lag, catch these bugs before they ship.

Deploys and failover

Replica promotion changes which node is the primary. Applications must reconnect and handle a brief unavailability window. Pipelines that test failover, not just the happy path, are what make a promotion routine instead of an incident.

Topology-aware integration tests

Reproducing a primary-plus-replica setup in CI is heavier than a single instance. Warm runners (such as Latchkey) keep that more realistic topology affordable on every run.

Key takeaways

  • A database replica is a synced copy used for read scaling and failover.
  • Replication lag means a replica can briefly be behind the primary.
  • Reading your own write from a replica too soon is a classic intermittent bug.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →