Introduction to distributed data

The distribution of data involves creating copies of data for dissemination between two or more geodatabases or services.

Data distribution improves data availability and alleviates issues such as server contention and slow network access to a central server. This can help an organization balance the load placed on a geodatabase between users who perform edits and those who require access for read-only operations.

Distributed data is also useful when you need to perform edits in the field, disconnecting from the network entirely for an indefinite amount of time.

There are several ways to distribute your data in your organization.

Copy and paste

Some organizations achieve a level of data distribution by saving copies of their geodatabases and sending them to other offices. These offices can then work on the data, make edits, and send a copy of their updated geodatabase back to the main office. Here, edits are compared and coordinated to ensure that the data at the two offices remains in sync. This solution can work with careful communication; however, there are many opportunities for updates to be lost, and it can be difficult to keep the two geodatabases in sync.

Geodatabase replication

Geodatabase replication is a data distribution method provided through ArcGIS. With geodatabase replication, data is distributed across two or more geodatabases by creating a replica of only a part of or an entire dataset. When a dataset is replicated, a replica pair is created; one replica resides in the original geodatabase, and a related replica is distributed to a different geodatabase. Any changes made to these replicas in their respective geodatabases can then be synchronized so that the data in one replica matches the data in the relative replica. The term relative replica refers to the other replica in a replica pair.

The three types of geodatabase replication are checkout/check-in, one-way, and two-way.

  • Checkout/Check-in replication: The child replica can be in either an enterprise or file geodatabase.
  • One-way replication:
    • One-way, parent-to-child replication: The child replica can be an enterprise or file geodatabase.
    • One-way, child-to-parent replication: Both child and parent replicas must be hosted in an enterprise geodatabase.
  • Two-way replication: The child replica must be an enterprise geodatabase.


For all replica types, the parent geodatabase must be hosted in an enterprise geodatabase. Learn more about geodatabase replication types.

Geodatabase replication is built on top of the traditional versioning environment and supports the full geodatabase data model, including topologies, networks, terrains, relationships, and so forth. In this asynchronous model, the replication is loosely coupled, meaning that each replicated geodatabase can work independently, and all changes can still be synchronized. Since it is implemented at the geodatabase level, the respective DBMS used by each related replica may differ. For example, one replica geodatabase can be built on top of SQL Server, while the other is built on top of Oracle. To get started, see how to prepare data for replication.

Geodatabase replication can be used in connected and disconnected environments. It can also work with local geodatabase connections, as well as a geodata service, which allow you to access a geodatabase through a local area network (LAN) or the internet using ArcGIS Server.

Geodatabase replication in ArcGIS Pro supports the following geodatabase data types:

  • Table
  • Feature class
  • Annotation
  • Dimensions
  • Relationship class
  • Topology
  • Network dataset**
  • Terrain dataset

    **Supported with limitations


Geodatabase replication in ArcGIS Pro only supports synchronization of data that is registered using traditional versioning. While geodatabase replication supports the full geodatabase data model, there are some datasets that cannot be edited in ArcGIS Pro, such as geometric networks. For a complete list of supported data types and limitations of geodatabase replication in ArcGIS Pro, see Replication and geodatabase compatibility.

Take a map offline with feature service sync capability

The Sync capability with feature services allows you to take maps offline by clicking the Download Map button.

When the data is taken offline, the layers in the map are updated to reference a local copy of the data. This allows you to make edits and complete your work without the requirement to be connected to the network. Once network availability is restored, you can upload your local edits made to the offline feature layers using the Sync button. If you no longer need to work offline, you can remove the local geodatabase and go back online by clicking the Remove button. This process points the layers' source back to the feature service, and the map display updates to show the current data for the web feature layers. See Take a map offline to learn more about how to configure this workflow.


The data source tab can be used to determine which layers are offline and which ones are not. Some types of layers in the web feature layer cannot be taken offline. These will remain connected to the web feature layer even if a local copy if the data is downloaded for other layers. When a network connection is not available, any layers that are still connected to the web feature layer will display as broken in the map. For more details, see Take feature layers offline.

Feature service sync versus geodatabase replication

Taking a map offline using the feature service sync capability is feature services based, whereas geodatabase replication uses local enterprise and file geodatabases. The key benefit of taking a map offline using feature service sync capabilities is the ability it provides to perform multiple synchronizations versus the checkout replica type, where changes can be synchronized only once.

DBMS replication

Various DBMS have their own replication mechanisms in place, which can be used to make copies of, and synchronize geodatabase data.

DBMS replication refers to the built-in replication mechanisms provided by the DBMS in which the geodatabase is stored. DBMS replication is not geodatabase aware. This means that geodatabase constructs, such as relationship classes and utility networks, are not known by the DBMS. However, DBMS replication can still be configured to work in a limited way with geodatabase data.

DBMS replication versus geodatabase replication

The following facts compare geodatabase replication and DBMS replication:

  • Geodatabase replication synchronizes changes from specific enterprise geodatabase versions. DBMS replication, when used with an enterprise geodatabase, applies changes across all versions in the geodatabase.
  • Geodatabase replication supports some advanced geodatabase objects such as topologies, relationships, and feature-linked annotation. DBMS replication does not properly replicate advanced geodatabase objects.
  • Geodatabase replication allows you to replicate portions of your geodatabase. DBMS replication used with a geodatabase requires that you replicate the entire database.
  • Geodatabase replication allows two-way replication. DBMS two-way replication is not supported against a geodatabase.

Distributed collaboration

With distributed collaboration, you can extend the reach of your GIS content by seamlessly sharing maps, apps, layers, and more with other organizations. Distributed collaboration (or simply collaboration) is based on a foundation of trust between participating organizations and is motivated by common goals and initiatives that support data access and sharing. Collaborations can be useful for many workflows, including exposing ArcGIS Enterprise content to the public through ArcGIS Online, making data visible across different departments in an organization, or managing field data collections. There is no single pattern for collaboration, so you can implement it in the way that best suits your needs.

Distributed collaboration supports referencing or copying feature services (feature layers). If you choose to copy feature services, you will first need to enable sync. See more about preparing your data for collaboration in Prepare data for offline use and About sharing feature layer and view data as copies.

Related topics