What is database replication, and why is it important?

What do database management systems (DBMS) need? A database that serves a billion users must store data safely, deliver it at speed, and stay available without interruption. Database replication does this. 

What is database replication?

Database replication copies complete database objects and states across multiple databases for data redundancy, durability, availability, and performance.

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 abstractions, such as database structures, schemas, and supporting logic. Data replication is like copying a file, while database replication is like copying a file system with an operating system 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 fewer interruptions or delays. Having up-to-date copies in multiple locations lets data bypass regional issues such as power or network outages. It also spreads load out across multiple servers to help prevent crashes and timeouts for 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 meant they kept serving customers without missing a transaction. Database replication provides 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, and decrease latency when fast transactions are important. Multiple servers balance high loads to spread out I/O and processing delays, and reduce the effect of network congestion. Replicas placed closer to users in edge data architectures reduce transit times, making them even faster.

Database replication for data localization

Replication, especially advanced replication with field-based filtering, makes it easier to comply with regional data safety, provenance, privacy, and sovereignty rules. Database replication helps companies maintain multiple copies of their database that are filtered and controlled for regional laws and customs, so data follows regulations.

In a financial fraud detection system, to accurately identify and prevent fraudulent activity, the system needs to analyze millions of customer records per second 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 work. Database replication lets multiple servers handle fraud score requests by routing each one to the least busy cluster, reducing bandwidth congestion, or to the nearest cluster, reducing latency for a faster response. 

If one of the requests comes from a country with strict data protection laws, a filtered local replica handles it while complying with those laws, while still allowing some activity data to be passed to global servers so customer activity within a strict jurisdiction doesn't become isolated.

How does database replication work?

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

Many techniques deal with these challenges, but the process is largely the same across the board:

• Capture changes at the source, using techniques such as change data capture (CDC), logging individual operations such as SETs, or using point-in-time (PIT) snapshots of source database state.

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

• Apply the changes to the replicas.

• Synchronize all instances so they're consistent and show the most recent, correct data. This might involve using a conflict resolution mechanism such as 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 many ways to categorize replication techniques, but the two most common classification approaches are based either on which nodes accept write requests, or replication topology, or when a write transaction is considered complete. The type of replication mode matters for data consistency, replication lag, and other considerations, so selecting the right data replication strategy is important.

Database replication types by topology

Four primary topologies are commonly used.

Active-passive database replication

In active-passive topologies, one primary database accepts new data and then sends it to one or more secondary database nodes for replication. The replica database or databases may be read-only replicas, which let users read from but not write to the replicas, or they may be 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 conflict resolution to keep them aligned.

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 may be active-active or active-passive, with the difference 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 from one node to another, but without necessarily replicating every piece of data on every node. Mesh database systems can rebuild the full database 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 mesh databases.

Database replication types by synchronicity

These 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. 

The advantage of synchronous replication is that it provides strong and immediate consistency across all the nodes, meaning each copy contains the same data in the same state at all times. This makes it resilient with low potential for data loss and no need to resolve conflicts.

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

The disadvantage of synchronous database replication is that because 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 for the 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 moves on to the next transaction.

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

Asynchronous replication is 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.

However, because the primary doesn't wait for confirmation of updates across the system, different nodes might have different data at any given time. This means it’s more likely that some data could be lost in 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 methods in a compromise that has fewer weaknesses, but also fewer strengths. Because it is cumbersome to set up and manage, it 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 careful logic and planning so it works correctly.

Database replication subtypes and concepts

Within these broader types, many subtypes handle specific replication details.

Snapshot replication: Takes a point-in-time copy of a database and stores it as a replica. The snapshot captures the database state in full, but is static and doesn't reflect data changes that happen after replicating.

Incremental replication: Uses CDC to replicate a database as it's altered to reflect the latest state of the data. Incremental replication may start with a snapshot and modify it to update the replica, or it may begin with a clean database and record only 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 records changes only if the entire transaction succeeds.

Challenges of database replication

While replication is important for DBMSes and applications to work, it's challenging. Many work as sliders on a single scale, meaning removing one challenge introduces another. Finding the best solution means identifying a compromise that works for a specific situation.

This balance is best described by the CAP theorem proposed by computer scientist Eric Brewer in 2000 and mathematically proven in 2002. 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 run 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 makes a system slower than a database without it. Sources of latency include:

• Processing overhead, required to start the replication process, puts together 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.

• Sending data to remote servers adds transmission latency that increases with distance, even though durability and availability generally increase the further nodes are from each other. This is primarily a problem with synchronous systems, but is also an issue for data freshness and consistency.

• Response times in synchronous databases slow down throughput, especially if nodes are far apart or a node is offline, forcing a delay for the full timeout length.

Failure handling

Node failure forces an immediate question: Does the system wait for the failed node to recover, promote a replica to primary, or reroute traffic and reconcile later? Each path has different consequences for data loss and availability windows. Developers need to make many choices early in the design process, even though the consequences may not be evident until 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 immediate consistency, all nodes report the same data at all times, at the cost of latency and throughput. Eventual consistency delays convergence by some amount, leading to users occasionally receiving stale data, but it's faster and handles 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. Delayed convergence risks serving stale data, but results in a faster and more available system.

Conflict resolution

Resolving data conflicts between nodes in the system is complex. 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 so that it isn't lost and the system eventually reaches a consistent state. No one mechanism fits every system, and there is no "right" way to do it; it depends on the needs of a given system.

The simplest mechanisms are where either the most recent conflicting write takes precedence (LWW), or the first conflicting write takes precedence (FWW). Another example is per-bin replication, which not only reduces latency and resource use, but also results in fewer conflicts. In per-bin replication, "bins," like columns in relational databases, are replicated individually when they change, rather than replicating an entire record. Replicating bins individually means two nodes write to the same record without causing a conflict if the writes changed different bins. A newer approach that isn't available on all DBMSes is Conflict-free Replicated Data Types (CRDTs). These are data structures designed to avoid the most common conflict issues. They use mathematical properties so data merging happens the same way regardless of order or timing. Examples include GGrow-only Counters (G-Counters), which are numerical counters that only grow, and LWW Registers, which use timestamped per-bin replication to keep a record of when each item was last changed.

Another issue with conflict resolution is avoiding 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 servers end up divergent. If many users make decisions based on divergent data, their choices would need to be 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

Here are some additional replication features to keep in mind.

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

Replication also scales systems up or down as needed by using replication to create a 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 creates a node with the core schema and structure and lets it fill up with new users without bringing over existing user data. Some database replication features, such as Aerospike XDR rewind, allow for granular recovery options that let developers return their data state to any specific transaction or point in time. iBn-level replication requires fewer resources and causes fewer conflicts because the data to be replicated is more limited and granular.

The CAP theorem specifies that out of consistency, availability, and partition tolerance, only two out of three requirements can be guaranteed. But database replication has more tradeoffs than that. Most DBMSes have a number of levers and dials to fine-tune parameters to meet specific needs, such as setting Aerospike XDR replication to Ship Always or Ship At Least Once in a Time Period to adjust resource use versus data loss risk.

Replica nodes may be in many 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.

Similarly, replication may occur within one cluster, across multiple clusters, or even outside the cluster, each with preferences for the database replication types that work best. For extra-cluster replication, DBMSes need to support a way to export data continuously, often through connections to data streaming platforms such as Kafka or Pulsar.

Database replication tools

Replication architectures need software to capture, transmit, and apply changes across nodes. Tools to do this range from database-native replication engines built into the DBMS to standalone CDC platforms, managed ETL pipelines, and replication brokers. Each category solves a different problem, and selecting the wrong one either limits performance ceilings or adds more work. 

Native database replication engines

The best-performing replication is typically the replication built into the database itself. Native engines run at the storage layer, with access to transaction logs and internal data structures that external tools must reverse-engineer through connectors and APIs.

• PostgreSQL ships with streaming replication, using write-ahead log (WAL) shipping to propagate changes from a primary to one or more standbys. It supports both synchronous and asynchronous modes and can be extended with logical replication for selective table-level replication across heterogeneous versions. 

• MySQL offers Group Replication for multi-primary topologies, with built-in conflict detection and failure handling across cluster members. 

• Oracle Data Guard handles synchronous and asynchronous log shipping for Oracle Database environments, focusing on standby maintenance and role transitions during failover.

Native engines have one limitation: they replicate within the same database engine. Moving data from MySQL to PostgreSQL, or from any relational system to a distributed NoSQL store, requires different tools. 

Aerospike's Cross Datacenter Replication (XDR) runs on the same basic principle: replication is part of the database architecture rather than an external add-on. XDR uses an asynchronous log-shipping model optimized for high-throughput, low-latency workloads, with bin-level filtering to control which data crosses datacenter boundaries. This makes it particularly suited to active-active global deployments with replication bandwidth and latency SLAs.

Change data capture platforms

CDC platforms decouple the capture mechanism from the database engine, so it streams changes from a source system to any downstream target, such as a data warehouse, a message queue, another database, or a real-time analytics platform. They read transaction logs or uses triggers in environments where log access is restricted and emits a structured stream of insert, update, and delete events.

• Debezium is the most widely used open-source CDC engine. It publishes change events to Apache Kafka, making it suitable for organizations already running Kafka-based data infrastructure. Debezium manages schema evolution well, but running the operational infrastructure around it still requires ongoing expertise and maintenance. Companies without a specialized infrastructure/platform team may find that to be too much work.

• Striim not only moves database changes in real time, but also modifies, cleans, enriches, or filters the data while it is being transferred.  Its visual pipeline builder makes it easier for non-engineering teams to use.

• Streamkap and Popsink are newer products targeting production-grade, low-latency CDC. Both products claim to be better than typical ELT tools because they place less load on the source database and automatically handle database schema changes. 

The tradeoff across CDC platforms is complexity versus flexibility. Debezium supports many systems and has a strong user community, but teams must manage the supporting infrastructure themselves. Commercial platforms are less work but introduce licensing costs and vendor dependency.

ETL and ELT replication tools

ETL (extract, transform, load) and ELT (extract, load, transform) tools do different things. They are best for moving data between operational systems and analytical targets such as data warehouses, data lakes, and business intelligence platforms rather than for low-latency replication between live databases.

• Fivetran is the category leader for managed ELT, offering pre-built connectors to hundreds of sources and targets with an emphasis on needing less configuration. It transfers historical data quickly, but it is too slow for tasks that require data to stay updated within seconds. 

• Airbyte is an open-source alternative that does about the same thing, with a self-hosted deployment option that gives engineering teams more control over data residency and connector customization.

• Estuary Flow occupies a middle ground, offering continuous data movement with sub-second latency for some connector configurations. It’s closer to a CDC platform than a traditional ELT tool. It targets teams that need real-time data movement without having to deal with running Kafka and Debezium themselves.

ETL and ELT tools are the right choice when the destination is analytical and handles latency of minutes. They are the wrong choice when the replication target is a live operational database serving user-facing requests.

Enterprise replication brokers

Enterprise replication brokers handle heterogeneous replication. They move data between different databases and cloud systems, including in regulated environments where changes must be tracked, and processing is built into the pipeline.

• Oracle GoldenGate is the classic in this category, with decades of production deployments in financial services, telecommunications, and government environments. It supports bidirectional replication across Oracle, SQL Server, MySQL, PostgreSQL, and several cloud data warehouses, with conflict resolution logic that can be customized at the column level. Its operational complexity and licensing cost reflect its enterprise positioning; GoldenGate is infrastructure that requires dedicated administration.

• Qlik Replicate (formerly Attunity) targets similar environments with a focus on cloud migration and real-time data warehouse loading. Its strength is breadth of connectivity: it supports more than 50 source and target endpoints, making it useful in organizations running heterogeneous data stacks with legacy systems that are older than CDC tooling.

• IBM InfoSphere Data Replication serves mainframe-to-cloud pipelines, which remain relevant in industries that still use IBM Z systems. It provides bidirectional replication with transformation and filtering, and integrates with IBM's broader data governance suite.

How to evaluate replication tools

Four primary characteristics determine which tool category fits a given requirement:..

1. Latency tolerance. A fraud detection system that must return a score within 100 milliseconds cannot handle a replication pipeline with 15-minute batch intervals. It requires either native replication or a CDC platform with sub-second delivery commitments. In contrast, an overnight analytics pipeline loading a data warehouse has no such constraint and benefits from the simplicity of a managed ELT tool.

2. Topology type.  Homogeneous, same-engine deployments can use the database's built-in replication. Cross-engine or cross-cloud topologies require a CDC platform or enterprise broker.

3. Operational overhead. Open-source tools such as Debezium or Airbyte are more flexible, but organizations have to manage them themselves. Managed commercial tools shift that burden to the vendor, but cost money every month. 

4. Target heterogeneity, or the number and diversity of downstream systems receiving replicated data. One primary-to-replica configuration favors native replication. A source database feeding five downstream targets across two cloud providers favors a CDC platform with a fan-out architecture.

Saving money on replication data 

Most replication cost analysis stops at the processing cost of running replica nodes, without considering the data expense. 

Hyperscalers charge for data movement between availability zones and between regions. On AWS, inter-region traffic runs $0.01–$0.02 per GB. On Google Cloud, a Cloud SQL instance replicating 100 GB per day across regions incurs approximately $360 per month in transfer fees alone — before accounting for the replica instance itself. Because replication traffic goes up with write volume, the cost also goes up when systems are under the heaviest load. A PostgreSQL primary-replica setup with synchronous replication across availability zones generates a billable transfer event on every write operation, continuously, whether traffic is high or low.

Disk-based databases are worse because they use page-level I/O. In other words, when just one field in a record changes, the entire database page containing that record is marked dirty and must be flushed. Then, when replication comes around, it propagates that full page, not just the changed field. The replication stream ends up carrying more data than the changes to the dataset.

For global deployments replicating across two or three regions, the difference in transferred data volume saves money.  In high-write environments, such as fraud detection, session management, and real-time bidding, where millions of records are updated per second, that reduction is big enough to consider when you’re deciding on architecture, alongside compute and storage costs.

The business cost of replication lag

Replication lag is typically calculated as seconds of delay between a write on the primary and its appearance on a replica. The business translation of that metric is more useful:

• In a fraud detection system, lag is the time during which a fraudulent transaction can be authorized against stale state. If a customer's account has been flagged after a suspicious transaction and that flag takes 800 milliseconds to propagate to the replica serving authorization decisions, every authorization request processed during those 800 milliseconds runs against data that does not reflect the current risk profile. At millions of transactions per second, that adds up.

• In real-time bidding, lag affects frequency caps and brand safety filters. An advertiser's frequency cap of five impressions per user per hour is enforced against whatever the serving node believes the current count to be. If the replica serving a particular region is 200 milliseconds behind, a user who has already hit the cap in another region may be served additional impressions before the updated count arrives. That wastes money, as well as the regulatory or reputational risk that frequency caps are intended to prevent.

This is true for any latency-sensitive applications: The lag tolerance of the replication system limits the precision of any business logic that reads from a replica. That’s a problem in systems where that logic controls money, risk, or user experience. 

In contrast, Aerospike's in-cluster replication runs synchronously within a data center by default, using a peer-to-peer mesh where each write is confirmed across the configured replication factor before the transaction completes. There is no primary bottleneck serializing replication requests. The result is that reads from any node in the cluster reflect the current write state: The lag between a write and its availability for reads is measured in microseconds, not milliseconds. For XDR, the asynchronous model introduces geographic propagation delay, but the replication stream itself still runs the same way, reducing the time data spends in transit.

When replication lag has a potential cost, that cost needs to be considered in infrastructure decisions, which may require sub-millisecond replication. 

Replication for AI infrastructure

Production AI applications depend on the same infrastructure features high-performance databases need, such as low latency, high throughput, and consistent data across distributed nodes. However, they have additional requirements based on how machine learning systems read data.

Feature stores and data freshness

A feature store holds precomputed features that a model uses for inference, such as user history, session context, risk signals, and behavioral aggregates. The accuracy of a model's predictions is limited by how fresh its features are. A recommendation model reading from a feature store with a two-minute replication lag is making decisions based on a user's state two minutes ago. In applications where user intent is the primary signal, such as content recommendations, real-time personalization, and next-best-action systems, two minutes is long enough to make the prediction useless.

Feature stores serving low-latency inference pipelines require the same properties as any operational database under high read throughput: consistent replication across serving nodes, sub-millisecond read latency, and the capacity to hold datasets bigger than available RAM. Aerospike's patented Hybrid Memory Architecture addresses the third constraint — by tiering across RAM and NVMe storage. That means it holds bigger feature stores than pure in-memory systems can afford, with the read latency inference pipelines require.

Vector indexes and retrieval-augmented generation

Retrieval-augmented generation (RAG) pipelines retrieve relevant documents or records from a vector index and supply them as context to a language model during inference. The quality of that retrieval depends on the index being current. An index that does not reflect documents added or updated in the last several hours will miss relevant context. 

Multi-region RAG deployments make this worse. If the vector index is replicated across serving regions and those replicas are out of sync, users in different regions may receive different responses to identical queries because the context differs. Replication consistency across vector index nodes is a correctness requirement, not a reliability one.

Inference pipelines and session state

Real-time inference at the authorization layer for functions such as fraud scoring, content moderation, and dynamic pricing requires millisecond access to user state across distributed serving nodes. Session context, rate limit counters, and risk signals must be consistent across every node that could receive a request for a given user. In systems where requests are load-balanced across regions, a serving node that cannot read current state from its local replica must either wait for a cross-region read, increasing latency, or proceed with stale data that may be inaccurate.

The replication architecture for inference session state is the same as the replication architecture for any low-latency task. What changes is the consequence of getting it wrong. 

• In a fraud system, stale data could mean a financial loss. 

• In a content moderation system, stale state could be a policy violation. 

• In a dynamic pricing system, stale state could mean lost money. 

Real-time applications need database replication

Database replication is one of the most important parts of designing an application or service. In fact, replication is required for 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 solution that works for every situation. The best 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 situation.

“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. Best-of-breed database management systems such as 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.