Esri Geodatabase Replication


Users of an Esri Geodatabase are increasingly confronted with an increased demand for availability and actuality of data in the Geodatabase — and 24x7 availability has become the rule rather than the exception. The management organization (functional and technical management alike) also has its own wishes and requirements, in addition to the wishes of the user organization. Reliability and robustness play a role in the way production data is made available. Above all, these days an increasing number of strict requirements are set for security, authorization, configurability and, last but not least, performance in general.

In this article we want to explain a solution from Esri with which, in addition to the (main) production database (read here Geodatabase), a second database is made available with which the increasing demand for availability can be met and with which the production database is also relieved, which normally has a favorable effect on the response times for the users (viewers and editors).


The solution that Esri has developed for this is called "replication." This article is based on the replication between two Sde Geodatabases. There are possibilities (with limitations) to work with file and/or personal geodatabases. Check-in/Check-out replication is an option for example, but this is not covered in this blog (after synchronization of changes a new check-out replica must be made).

Geodatabase replication is a method to distribute data using ArcGIS. At least two geodatabases are involved (> 2 is also possible). The complete data set — or a part thereof — is replicated. If a data set becomes part of a replica, a so-called "pair" is created. Part A of the replica is in the main/production geodatabase (parent) and part B of the replica is in the 2nd geodatabase (often called child geodatabase). This second geodatabase can in practice be seen as a publication database, specifically made available to users who only consult. The publication database can also be used by third-party applications — such as, for example, a Wion application/system, where high demands are usually placed on availability.

An additional advantage of putting a publication database into use is that in the case of migrations or system maintenance to the production environment, the publication database remains up and running at that moment. After maintenance to the production/edit environment, the management organization can carry out the same maintenance work on the publication database at a date to be determined.


1-way replication: data updates can be sent multiple times in one direction, either from parent (main) database to child database (parent is editable, data in child is considered read-only), or from child to parent (data in child is editable, data in parent is considered read-only).

2-way replication: data updates can be sent several times in two directions, so both from parent to child and from child to parent. If the same object has been changed in both databases, this is considered a conflict during synchronization of the replicas. It is configurable how conflicts should and could be resolved where appropriate.


Changes to data in the replicas are implemented via synchronization between the replicas. The synchronization is carried out via Python and/or ArcMap. Python scripting facilitates scheduling the synchronization at a set time (near real-time). Logging is also available.


Replication sets requirements for the data model (the global_id attribute should be present) and for the versioning. These requirements are not complex and easy to set up with out-of-the-box tools. The replication method is built on the versioning mechanism. This also provides a way to handle conflicts in a controlled manner.


Do you want to know more about this topic?

Schedule an appointment and let us advise you!