What is database replication, and why is it important?

What are the core requirements for a modern database management system? It needs to store data safely and accurately and deliver it quickly to where it needs to go. It also needs to be able to meet demand and scale up or down based on volume. And it needs to stay available so it's accessible at any time. Database replication is the critical core functionality that supports all of these requirements.

What is database replication?

Database replication is the copying of complete database objects and states across multiple databases to ensure data redundancy, durability, availability, and performance.

Importantly, database replication is not the same thing as data replication. The difference is one of scope:

Data replication copies the specific bytes that make up individual files or other data. Database replication takes place at a higher level than data replication and includes abstracts like database structures, schemas, and supporting logic. Put another way, data replication is like copying a file, while database replication is like copying a file system with an operating system (OS) included.

All database replication includes data replication; not all data replication is part of a database replication process.

Database replication is a foundational concept for modern database systems and the applications and services these systems support.

Why is database replication important?

"The only sure way to ensure that such services can survive catastrophic infrastructure failures is to deploy the DBMS as well as the applications themselves on multiple sites that are hundreds (or even thousands) of miles apart from each other."

-V. Srinivisan, et. al.,
Asynchronous Replication Strategies for a Real-Time DBMS,
SIGMOD 2025

The goal for any application is to deliver the same high-quality experience to both the first and billionth user while ensuring uninterrupted service. Database replication is the technology that allows this to happen. There are many types and techniques for database replication, which provide a wide range of benefits.

Database replication for high data availability

Replicating databases across geographically distributed servers maintains access to data with minimal interruptions or delays. Having up-to-date copies in multiple locations lets data bypass regional issues like power or network outages. It also spreads load out across multiple servers to prevent crashes and timeouts and ensure high availability.

Database replication for disaster recovery

When Hurricane Sandy struck New York in 2012, high winds and flooding not only knocked out the main power but also many backup systems, including Nielsen Marketing Cloud. Redundant replicas outside the affected area allowed them to keep serving customers without missing a transaction. Database replication makes for resilient data and allows for continuous operation and rapid recovery of affected nodes once the disaster has been dealt with.

Database replication for performance

Replica servers running identical databases give users faster access and a better experience, or decrease latency when lightning-fast transactions are critical. Multiple servers can balance high loads to spread out I/O and processing delays, and minimize the impact of network congestion. Replicas can also be placed closer to users in edge data architectures to reduce transit times, increasing speed even further.

Database replication for data localization

Replication, especially advanced replication with field-based filtering, makes it much easier to stay compliant with regional variances in data safety, provenance, privacy, and sovereignty rules. Database replication allows companies to maintain multiple copies of their core database that are filtered and controlled for regional laws and customs, ensuring data never runs afoul of regulations.

How does all of this work together to make for a better application and service? Imagine a financial fraud detection system. To accurately identify and prevent fraudulent activity, the system needs to analyze a lot of customer data, and it needs to do so in a fraction of a second.

“Hundreds of reads and dozens of writes are typically required to calculate a fraud score within 100ms.”

Every financial transaction analyzed is a big lift, and there can be millions of transactions per second. Database replication enables multiple servers to handle fraud score requests by routing each one to the least busy cluster (reducing bandwidth congestion) or to the nearest cluster, cutting latency for a faster response. In some cases, it can do both. 

And if one of the requests comes from a country with strict data protection laws, a filtered local replica could handle it without violating those laws. This can occur while still allowing some activity data to be passed to global servers so customer activity within a strict jurisdiction doesn't become an isolated black box.

How does database replication work?

Replicating an entire database can be a challenge, especially if it's busy and changes frequently, and even more so if every replica accepts writes (an active-active configuration). The DBMS has to monitor each database for changes, disseminate those changes across every node, and resolve any conflicts when multiple source databases try to change the same field in different ways.

A lot of varying techniques have been developed to deal with these challenges, but the core process is largely the same across the board. This process is:

1. Capture any changes at the source, using techniques like change data capture (CDC), logging individual operations (e.g., SETs), or using point-in-time (PIT) snapshots of source database state.

2. Transmit the changes to replica servers, either directly or by propagating from server to server.

3. Apply the changes to the replicas.

4. Synchronize all instances to ensure they're all consistent and show the most recent, correct data. This might involve using a conflict resolution mechanism like Last Write Wins (LWW), First Write Wins (FWW), a conflict-free replicated data type (CRDT), or custom logic built to meet the needs of a specific application.

What are the types of database replication?

There are countless ways to categorize replication techniques, but the two most common classification approaches are based either on which nodes accept write requests (replication topology) or when a write transaction is considered complete. The type of replication mode can have significant consequences for data consistency, replication lag, and other considerations, so selecting the right data replication strategy is imperative.

Database replication types by topology

Four primary topologies are commonly used.

Active-passive database replication

In active-passive topologies, a single primary database accepts new data and then sends it to one or more secondary database nodes for replication. The replica database (or databases) can be read replicas, allowing end users to read from but not write to the replicas, or they can be completely internal with no public access, often used for backups.

Active-active database replication

Active-active topologies have multiple source nodes that accept writes and multiple replicas, and often have nodes that are both source and replica at the same time. This topology requires thorough conflict resolution to avoid significant divergence.

Multi master replication (MMR) is a common replication architecture that refers to data strategies that use active-active replication across nodes. The two are often used interchangeably, with the only difference being that MMR is a broader and more inclusive term. Master master replication is another way to refer to Active-active topologies.

Star database topology

The database system is structured as a central hub with a series of satellites. Star topologies can be active-active or active-passive, with the key distinction being that satellites cannot communicate with each other, and all replication is mediated by the hub. This topology is commonly used in edge computing/edge data applications.

Mesh database replication

Forming the backbone of many advanced projects, mesh databases use peer-to-peer replication where all or some data is replicated directly from one node to another, but without necessarily replicating every piece of data on every node. In mesh database systems, the full database can be rebuilt from any arbitrary collection of nodes, depending on the configuration. These systems are complex to execute well and have additional challenges, making them less common in commercial systems. Some blockchain systems are an example of mesh databases.

Database replication types by immediacy of replication

The following database replication types are classified based on when the data is considered replicated and the effect it has on other transactions.

Synchronous database replication

In synchronous replication, incoming data is written to the primary database and immediately sent out to replicas for writing. The initial write is not considered finished until the primary receives and acknowledges confirmation that the replicas have successfully updated. 

Advantages of synchronous database replication

Synchronous replication ensures strong and immediate consistency across all the nodes, meaning every single copy contains the exact same data in the exact same state at all times. This makes it resilient with low potential for data loss and no need to resolve conflicts.

Disadvantages of synchronous database replication

“Most high-performance consumer applications cannot tolerate the high write latencies required for synchronizing writes across far-apart sites.”

Since transactions are incomplete until all replicas confirm the update status, further transactions are blocked until the first one completes. This makes these systems slow, especially if a replica goes offline and the primary has to wait the entire timeout period.

Asynchronous database replication

In asynchronous replication, incoming data is written and sent out for replication, just as with synchronous replication. But rather than waiting for confirmation, the primary self-acknowledges the update and immediately moves on to the next transaction.

Advantages of asynchronous database replication

“Asynchronous replication becomes the only practical option for these [real-time] applications.”​

Asynchronous replication is much faster than synchronous replication, making it a better fit for real-time applications that require low latencies and high throughput. Systems are usually eventually consistent.

Disadvantages of asynchronous database replication

Since the primary doesn't wait for confirmation of updates across the system, different nodes might have different data at any given time. This introduces a higher possibility of some data being lost in the event of an incident, and requires more complex logic to deal with conflicts and collisions between servers over the correct state of the data.

Semi-synchronous database replication

This is a blended approach where some data is updated synchronously and some is updated asynchronously based on predetermined rules. This approach balances the advantages and disadvantages of both main methods in a compromise that has fewer weaknesses, but also fewer strengths. It can also be cumbersome to set up and manage, and is not commonly used.

Multi-modal/hybrid database replication

This is a newer approach that uses conditional logic to decide which form of replication is most appropriate at any given time based on which piece of data is modified: the table being updated, the type of transaction, the region, or any other program-accessible variable. Unlike semi-synchronous replication, the decision on which type to use happens dynamically at the time of change, making this approach more flexible. However, it requires more careful logic and planning to ensure it works correctly even in edge cases.

Database replication subtypes and concepts

Within these broader types, a large number of subtypes handle the specifics of the what, when, and how of replication.

Snapshot replication: A replication strategy that takes a point-in-time copy of a database and stores it as a replica. The snapshot captures the exact database state in full, but is static and doesn't always reflect data change that happens after replicating.

Incremental replication: Uses change data capture (CDC) to replicate a database as it's altered in order to reflect the latest state of the data. Incremental replication can begin with a snapshot and modify it to get a full and updated replica, or it may begin with a clean database and only record new changes for partial replication.

Transactional replication: A specific type of incremental replication that captures every transaction recorded by the original database. Like all transactional actions, the target database only records changes if the entire transaction succeeds.

Challenges of database replication

While replication is critical to the functioning of modern DBMSes and applications, it's not without its challenges. Many work as sliders on a single scale, meaning removing one challenge intrinsically introduces another. Finding the optimal solution means identifying a compromise that works for a specific use case.

This balance is best exemplified by the CAP theorem proposed by computer scientist Eric Brewer in 2000 and mathematically proven in 2002:

CAP theorem: In any distributed system, only two of the following can be guaranteed:

• Data consistency: Every read will receive either the most recent write or an error, and all nodes always return the same data

• Data availability: Every request will receive a non-error response, even if it doesn't contain the most recent write

• Partition tolerance: The system will always continue to operate despite network partitions or failures in communication between nodes

In addition to this tradeoff, there are further challenges in database replication.

Added latency

While synchronous replication typically adds the most latency, any replication will make a system slower than a single-instance database. Sources of latency include:

• Processing overhead, required to initiate the replication process, composes the data package to distribute and deploy it to replica servers.

• I/O operations occur as replication requests are sent out, and confirmations (or data to be replicated) are received and written to memory or disk storage.

• Transmission latency is added when sending data to remote servers and increases with distance, even though durability and availability increase the further nodes are from each other. This is primarily a problem with synchronous systems, but can also be an issue for data freshness and consistency.

• Response times in synchronous databases can significantly slow down throughput, especially if distances between nodes are large or a node is offline, forcing a delay for the full timeout length.

Failure handling

Deciding how a distributed, replicated database handles node or replication failures adds complexity to data handling workflows. Developers need to make many choices early in the design process, even though the consequences may not be evident until much later.

Data consistency

Consistency is when a database reaches convergence, or a unified data state. The two most common options are immediate and eventual. 

In the former, all nodes report the same data at all times at the cost of latency and throughput. The latter delays convergence by some amount, leading to users occasionally receiving stale data, but it's much faster and can handle more transactions per second. 

In eventual consistency models, convergence may only be delayed by a few milliseconds or hours, depending on how the system is configured. This can hurt data integrity across the entire system, but makes for a much more available and low-latency design.

Conflict resolution

Resolving data conflicts between different nodes in the system is a complex enough topic that it could take up multiple white papers by itself. In asynchronous systems with multiple write-enabled primaries (Active-Active), conflicting data may be written to different nodes before consistency is reached. In those cases, the system has to decide which data state is the most correct one to ensure data isn't lost and the system can eventually reach a consistent state. The mechanisms to do this are varied, and there is no "right" way to do it — it depends on the needs of a given system.

• LWW/FWW: A simple system where either the most recent conflicting write takes precedence (Last Write Wins) or the first conflicting write takes precedence (First Write Wins).

• Per-bin replication: A system that can reduce latency and resource use, but can also result in fewer conflicts. In per-bin replication, "bins" (analogous to columns in relational databases) are replicated individually on change, rather than replicating an entire record (a collection of bins). Replicating bins individually means two nodes might have writes to the same record without causing a conflict if the writes changed different individual bins.

• CRDTs: A newer approach that isn't fully supported on all DBMSes. Conflict-free data types are data structures that have been engineered to avoid the most common conflict issues. These data structures use mathematical properties to ensure data merging is deterministic regardless of order or timing. Examples include G-Counters (or Grow-only Counters), which are numerical counters that can only grow, and LWW Registers, which use timestamped per-bin replication to keep a record of when each item was last changed.

An important issue with conflict resolution is the need to avoid cascading effects. For example, users might make decisions based on stale data that generates additional data changes, leading to more decisions and more new data until different servers have diverged to a massive degree. In these cases, conflict resolution can be touchy, to say the least. If many users make important decisions based on divergent data, they might be upset to see their choices rolled back.

Database replication in different database types

Different types of databases handle replication differently, which could have important implications for applications using them.

Advanced database replication concepts

In addition to the complexity involved in the core process of database replication, additional considerations, concepts, and features can radically change how replication works within a DBMS or which replication approach is best for a specific use case.

• Filtering: Some DBMSes allow for dynamic filtering during the replication process itself, allowing the system to decide which bins and records get sent to which replica nodes on the fly based on conditional logic (E.g., complying with data sovereignty laws by only replicating records to nodes located in that country).

• Replication as scaling: Replication can be used to scale systems up or down as needed by using the inherent replication process to instantiate a new node without having to do a full point-in-time backup and ingest of existing data. For example, an app with a sudden user spike can automatically instantiate a new node with the core schema and structure and let it fill up with the new users without immediately bringing existing user data over.

• Selective recovery: Some database replication features, like Aerospike XDR rewind, allow for incredibly granular recovery options that let developers return their data state to any specific transaction or point in time.

• Bin-level replication: Already mentioned earlier, bin-level replication requires fewer resources and causes fewer conflicts since the data to be replicated is more limited and granular.

• Replication tradeoffs: The CAP theorem tells us that only two out of three requirements can be guaranteed, but database replication has significantly more tradeoffs than just consistency, availability, and partition tolerance. Most DBMSes have a lot of levers and dials that can fine-tune parameters to meet specific needs (E.g., setting Aerospike XDR replication to Ship Always or Ship At Least Once in a Time Period to adjust resource use vs. data loss risk).

• Distribution and system architecture: Replica nodes can be located in a lot of different places, each with its own benefits and risks. Some examples include multiple on-prem servers, multiple datacenters, in the cloud, across multiple clouds, or a combination of any of these.

• Intra- vs. inter- vs. extra-cluster replication: Similar to the previous point, replication can happen within a single cluster, across multiple clusters, or even outside the cluster, each with preferences for the kind of database replication types that work best. For extra-cluster replication, DBMSes need to support a way to continuously export data, often through connections to data streaming platforms like Kafka or Pulsar.

Database replication is the bedrock on which modern real-time applications are built

Database replication isn't the most exciting part of designing an application or service, but it's one of the most critical. In fact, replication is non-negotiable for modern real-time applications: developers need to build it in, and they need to build it right.

The challenge for architects, developers, and designers is that there's no "best" solution that works across every use case. The optimal replication solution requires a thorough understanding of the pros and cons of available options, the dials and settings they offer to fine-tune functionality, and the priorities for a given use case.

“XDR supports high-throughput updates to remote clusters located hundreds of milliseconds of network latency away while minimizing the lag.”

Fortunately, that doesn't mean developers need to memorize spec sheets for every DBMS available. Modern best-of-breed database management systems like Aerospike 8 with XDR support multiple replication modalities and configurations and are sufficiently customizable to fit any need.

To learn more about database replication with Aerospike XDR, see our Chief Evangelist Srinivasan "Sesh" Seshadri's presentation at the 2025 SIGMOD conference in Berlin, or check out our XDR documentation.