Skip To Content

Enterprise data management strategies

Workflows using geographic data can vary widely in duration and complexity. Enterprise geodatabases support two data management strategies that balance the workflow needs of users and applications to perform short and long transactions on data: data management with versions and without versions. The nonversioned approach manages short transaction editing, and versioning accommodates long transactions. Each strategy, whether with or without versions, can be applied on a feature-class-by-feature-class or table-by-table basis, so it's possible to make use of both in the same enterprise geodatabase. Versioned data management is further expanded into three options: branch versioning, traditional versioning, and versioning with the option to move edits to base.

The strategy you choose will be determined by the capabilities that you want in your GIS, as there are some differences in which data you can edit and the types of workflows you can perform.

Data management without versioning

This strategy does not involve working with multiple versions of your data; it simply makes use of the underlying DBMS transaction model. Nonversioned edits are equivalent to standard database short transactions.

To edit data, click the Edit tab on the ribbon; then perform the required operations, such as adding, deleting, or moving features and updating attributes. Your first edit in the edit session begins the transaction, and the individual edit operations you perform are each committed to the database as a single transaction. When editing nonversioned data in ArcGIS Pro, each transaction is automatically committed to the database without needing to save the edits. The changes you make are available to all other users and applications accessing the data when your transaction is complete.

Editing nonversioned data

As you edit, any unique indexes, constraints, and triggers defined on the data with the DBMS apply. All the same locking behavior applies as if you were performing transactions on the data with the DBMS directly. Therefore, there is the potential for users or applications that access or modify the same data to block one another.


When using nonversioned editing in a multiuser editing environment, you should understand how isolation levels and locking work in your DBMS and, if necessary, set the correct isolation level in the DBMS before you start working with ArcGIS.

This strategy is appropriate for simple features for which you don't need to work with multiple representations of the data within versions. Since this strategy doesn't use versions, it's also useful if you require both GIS and non-GIS applications to share access to a common database.


Benefits of nonversioned data management include the following:

  • Easily integrate geographic data into existing applications by allowing third-party applications (those not created with Esri software) to read and modify the same data that is accessed by ArcGIS applications. For example, business partners of Esri frequently build add-ons and extension applications that require open access to update the data stored in the underlying DBMS.
  • Manage projects with simple workflows and edits. If transactions are always simple and of short duration, you can modify the data directly without the need to merge changes and periodically manage additional tables that are required for versions.


Limitations of nonversioned data management include the following:

  • You can only edit simple data: points, lines, polygons, annotation, and relationships. You can't edit feature classes that participate in a topology, network dataset, utility network, or other advanced datasets.
  • Since you edit the data source directly, you cannot undo or redo an individual edit if you make a mistake.
  • There is no conflict detection with nonversioned editing. If one user updates a feature and saves, and then another user updates the same feature and saves, the last update made overwrites the first.
  • In multiuser editing scenarios, as one user edits a feature, locks are applied by the DBMS, preventing other editors from making simultaneous edits to that same feature.

Data management with versioning

The enterprise geodatabase uses versioning to accommodate the needs of multiuser editing scenarios and long transactions. The geodatabase extends the standard DBMS transaction model by allowing multiple concurrent states of the databases, known as versions, to exist at the same time. This allows multiple users to edit the same data in the geodatabase at the same time, without applying locks or duplicating data.

Editors can work within their own personal version of the geodatabase so that other users don't see incomplete work and editors don't block one another from accessing the data.

Each version can represent ongoing work, such as a design or a group of work orders, work that can span multiple connections to the database and extend over a period of weeks or months if necessary. Once an editor has completed their work, they can integrate their changes back into the parent version.

Here are some example workflows using versions:

  • Projects requiring a what-if analysis: Create a new design in a separate version. If the design is approved, you can merge it with the rest of the database. If it is not approved, you can discard it.
  • Projects with specific quality assurance requirements: Collect changes to data, such as bulk imports, in a version isolated from other database users. Test and approve the changes before merging them with the published version of the database.
  • Projects that divide work into functional or geographic units: For example, a project to design and construct a new shopping mall might have distinct construction phases subdivided into east and west sections or by construction activities, such as building, utility installations, or landscaping. Each unit of work is undertaken in a separate version; as each version is completed, it is posted to the published version of the database.
  • Projects that evolve through a prescribed or regulated group of stages, whereby each stage requires engineering, administrative, or legal approval before it can be considered complete: Workflows for these projects can manage each stage as a separate version, such as an initial design or proposed version, an approved version, and a version for the construction phase. As a project advances through the various milestones, each stage is reviewed and approved, and then superseded by the next version until the last stage is reached and completed.
  • Projects that require maintenance crews in the field to update data with mobile devices. Editors in the field can work within their own versions and merge changes with the updates made by editors back in the office.

Every enterprise geodatabase has a version named Default. Unlike other versions, the Default version always exists and cannot be deleted. In most workflow strategies, it is the published version of the database, representing the current state of the system being modeled. You maintain and update the Default version over time by posting changes to it from other versions. You can also edit the Default version directly, just like any other version. The Default version is the root version and, therefore, the ancestor of all other versions.

Simple version tree

Versioning allows flexibility and scalability in your data management strategies. There are two types of versioning available, each catering to particular workflows and deployment options:

  • Branch versioning
  • Traditional versioning
    • Traditional versioning with the option to move edits to base

Branch versioning

The ArcGIS platform is a full Web GIS, a system of systems capable of sharing data across and between individuals, teams, and organizations. This is made possible by collaborating via services online or within an organization's portal. Branch versioning is the mechanism behind long transactions for services. If you require multiple editors concurrently accessing services with the ability to undo and redo their edits, you must first register your data as branch versioned.

When a dataset that is registered as branch versioned is shared as a service, you have the option to enable the Version Management capability at the time of publishing. This creates a version management service (VM Service in the image below) that facilitates the creation and management of versions. Editors can then begin working with feature services within their own versions, making updates to the data, and merging their changes back to the Default version when finished.

Editing with branch versioning


Benefits of branch versioning include the following:

  • The only way to get versioning and long transactions for feature services.
  • Undo or redo changes as you're editing feature services.
  • ArcGIS provides the ability to easily detect, reconcile, and resolve conflicts.
  • Conflict resolution can occur concurrently and over multiple sessions.
  • You can edit features in a utility network. This service-based dataset is only available using a Web GIS deployment.
  • Enhanced editor tracking capabilities allow you to also track users who delete features within a version.
  • Unlike traditional versioning, the compress operation is not required for geodatabases with branch versioned datasets.


Limitations of branch version include the following:

  • Can be used only in ArcGIS Pro and edited only with feature services.
  • Simple features and the utility network are currently the only datasets available for editing through branch versioning. If you would like to edit topology or a network dataset in a versioned environment, you'll have to work with traditional versioning.
  • Allows only one editor per branch version or multiple readers. Once an editor begins editing within a branch version, an exclusive lock is obtained and no further users can connect to the version.

Traditional versioning

If you are not working with feature services that require long transactions but still want the multiuser editing and workflow benefits provided by versions, you can use traditional versioning as your data management strategy. This gives you the flexibility to accommodate multiple editors and isolated versions to manage your workflows, such as what-if scenarios, predictive analytics, and work site proposals.

Traditional versioning is intended for users that will utilize multiuser editing workflows by accessing the enterprise geodatabase directly via the database connection. If you require the ability to work within versions for long transactions when accessed directly from the enterprise geodatabase, but you don't need this level of version management capabilities for data shared at the feature service level, use traditional versioning. Datasets can still be shared via feature services but will not have the same level of multiuser version management capabilities (for example, the version you publish from is the version you edit from and there is no undo or redo during editing).

There is no limit to the number of traditional versions an enterprise geodatabase can have. Versions can be arranged in various configurations and support a wide variety of workflows, including multilevel hierarchies with grandchildren versions, great-grandchildren versions, and so on. However, for the sake of simplicity and geodatabase management considerations, a recommended best practice is to either maintain a flat version tree or have multiple editors concurrently editing the Default version.

Editing with traditional versions


Benefits of traditional versioning include the following:

  • The isolated editing environment allows flexible, multiuser deployment scenarios.
  • Edit advanced datasets such as network datasets and topologies.
  • Undo or redo changes as you're editing.
  • Edit without blocking other editors. Editing conflicts can be easily detected and reconciled.


Limitations of traditional versioning include the following:

  • Depending on the number of versions and volume of edits, there are a number of version administration tasks that must be done regularly to keep your system performant.
  • Third-party applications must be adapted with versioned views before they can read data.
  • There are restrictions on the use of active DBMS behavior, such as unique constraints and triggers when working with versioned data.
  • No version management capabilities when working with services.

Traditional versioning with the option to move edits to base

In a heterogeneous computing environment where you have a number of different departmental applications accessing the same database, you may need to support both ArcGIS and third-party applications. If this is the case, you can register your data as versioned with the option to move edits to base. This is a hybrid data management strategy where you can still create versions for long transaction and multiuser editing requirements, but edits to the Default version are performed as short transactions and therefore immediately accessible to all applications accessing the database.

An example is one department that maintains the geographic data in the database with ArcGIS Pro and another department that maintains customer records in the same database with a custom application. The custom application needs to apply DBMS constraints and triggers as transactions are made and may not recognize versioned tables. At the same time, the other department needs to edit the geographic data in its own isolated version, not sharing the departmental edits until they are complete and approved.

With these requirements in mind, versioning with the option to move edits to base allows you to perform versioned editing on a feature class or table while retaining the ability to share edits with other applications. This allows all applications to work on the same database.

Editing with versions with the option to move edits to base


Benefits of versioning with the option to move edits to base include the following:

  • Shares many of the same benefits of traditional versioning.
  • Long transactions working in a named version and short transactions when editing the Default version.
  • Accommodates projects requiring concurrent data access by ArcGIS Pro and other applications.


Limitations of versioning with the option to move edits to base include the following:

  • You can edit simple data only: points, lines, polygons, annotation, and relationships. You cannot edit a feature class in a topology, network dataset, or utility network.
  • When you edit the Default version or post a version to Default, you do not have the ability to resolve conflicts, so it is possible to overwrite another user's edits.

For more information on versioning and the workflows it provides, see Versioning in ArcGIS Pro