14.4 Multiuser Geodatabase Architecture: Traditional Versioning, Branch Versioning & Archiving
Key Takeaways
- Multiuser geodatabases utilize optimistic concurrency control through versioning, allowing multiple editors to modify spatial data concurrently without acquiring table or feature locks, resolving conflicts during reconciliation.
- Traditional Versioning isolates edits using Delta tables—the Add (A) table for inserts and updates, and the Delete (D) table for deletions and pre-update records—while preserving the untouched Base table.
- Reconciling evaluates differences between an edit version and a target parent version (typically DEFAULT) and detects conflicts either by object (row-level) or by attribute (column-level), followed by posting resolved edits to the parent version.
- Branch-versioned tables use fields such as GDB_BRANCH_ID, GDB_FROM_DATE, and GDB_IS_DELETE, with deletion and archive metadata managed by the platform; GDB_TO_DATE belongs to classic archiving, not the branch row model.
- Temporal GIS distinguishes instants from intervals and valid time from transaction time; bitemporal models preserve both when a fact was true and when the database recorded it.
Multiuser Geodatabase Architecture: Traditional Versioning, Branch Versioning & Archiving
Quick Summary: In enterprise GIS environments, dozens or hundreds of editors must concurrently edit shared spatial datasets without overwriting each other's work. Traditional pessimistic database locking fails in GIS because spatial editing involves "long-running transactions" that can span days or weeks. To solve this, enterprise geodatabases implement optimistic concurrency control through versioning architectures. Mastering Traditional Versioning (delta tables, state trees, and compress operations), Branch Versioning, and historical archiving is vital for enterprise geodatabase administration.
Multiuser Concurrency Control: Optimistic vs. Pessimistic Architectures
Concurrency control governs how a database handles simultaneous read and write operations by multiple users on shared datasets.
Pessimistic Concurrency Control
In a pessimistic concurrency model, the database assumes conflicts are frequent:
- When a user opens a record or feature class for editing, the system places an exclusive lock on that row, table, or spatial extent.
- All other users are blocked from modifying or accessing the locked records until the first editor saves changes and releases the lock.
Why Pessimistic Locking Fails in GIS: Standard banking transactions execute in milliseconds. In GIS, however, transactions are long-running transactions—a utility technician may take three weeks to re-align parcel boundaries or design an electrical substation expansion. Holding exclusive database locks for days or weeks paralyzes an organization, creates deadlocks, and prevents concurrent multi-user editing.
Optimistic Concurrency Control
In an optimistic concurrency model, the database assumes conflicts are rare:
- Multiple editors concurrently view, query, and modify independent, isolated copies or views of the data without acquiring locks on the base tables.
- Changes are tracked independently in versioned states.
- When an editor finishes their work, changes are merged back into the master dataset through an explicit Reconcile and Post workflow, where any conflicting edits are identified and resolved.
Geodatabase Versioning is the industry-standard implementation of optimistic concurrency for geospatial data.
Traditional Versioning: Architecture, Delta Tables & The State Tree
Traditional Versioning (historically known as ArcSDE versioning) relies on a parent-child version hierarchy rooted in the DEFAULT version.
TRADITIONAL VERSIONING STATE TREE
[ DEFAULT Version ]
(Root Authoritative)
/ \
/ \
[ Project_Alpha ] [ Project_Beta ]
(Parent View) (Parent View)
/ \
/ \
[ Editor_1_QA ] [ Editor_2_QA ]
(Child Version) (Child Version)
Version Hierarchy and Access Permissions
- DEFAULT Version: The root of the version tree representing the published, authoritative state of the organization's geospatial assets. Every geodatabase contains exactly one DEFAULT version.
- Child Versions: Independent named branches created from the DEFAULT version (or another parent version) to isolate specific projects, geographic areas, or editor workflows.
- Version Access Permissions:
- Private: Only the owner of the version can view and edit it.
- Protected: Any database user can view the version, but only the owner can edit it.
- Public: Any database user with appropriate dataset privileges can both view and edit the version.
The Delta Tables: Add (A) and Delete (D) Tables
When a feature class or table is registered as versioned in an enterprise geodatabase, the system alters the underlying RDBMS schema:
- The original physical table becomes the Base Table.
- The system generates two associated delta tables in the database: the Add (A) Table and the Delete (D) Table.
+-----------------------------------------------------------------------------------+
| TRADITIONAL VERSIONING DELTA TABLES ARCHITECTURE |
+-----------------------------------------------------------------------------------+
| BASE TABLE (parcels): Contains the original untouched data as of registration. |
| [ObjectID: 101] | [Parcel_ID: A-1] | [Owner: Smith] | [Geom: Polygon101] |
| [ObjectID: 102] | [Parcel_ID: A-2] | [Owner: Jones] | [Geom: Polygon102] |
+-----------------------------------------------------------------------------------+
| ADD (A) TABLE (a_parcels): Records all INSERTS and updated states of features. |
| [ObjectID: 103] | [State_ID: 15] | [Owner: Baker] | [Geom: Polygon103] (Insert) |
| [ObjectID: 101] | [State_ID: 18] | [Owner: Davis] | [Geom: Polygon101] (Update) |
+-----------------------------------------------------------------------------------+
| DELETE (D) TABLE (d_parcels): Records all DELETIONS and previous updated states. |
| [Deleted_ObjectID: 102] | [State_ID: 12] (Deletion) |
| [Deleted_ObjectID: 101] | [State_ID: 18] (Pre-update state retired) |
+-----------------------------------------------------------------------------------+
How Edits Are Logged in Delta Tables
- Inserting a Feature: A new row is written directly into the A table, stamped with the current State ID of the version.
- Deleting a Feature: A record containing the target feature's Object ID and the current State ID is written into the D table. The feature is not removed from the Base table.
- Updating a Feature: An update is executed as a two-step operation: the prior state of the feature is recorded as retired in the D table, and the newly modified feature attributes and geometry are inserted into the A table under the new State ID.
How Versioned Queries Reconstruct Data
When a user queries a version, the geodatabase executes a dynamic relational view: it selects all records from the Base Table, subtracts any Object IDs listed in the D table for that version's state lineage, and appends the latest records from the A table corresponding to that version's lineage.
The Versioning Lifecycle: Reconcile, Conflict Resolution, Post & Compress
+-----------------------------------------------------------------------------------+
| THE COMPLETE RECONCILE, CONFLICT RESOLUTION, AND POST WORKFLOW |
+-----------------------------------------------------------------------------------+
| 1. EDITING: Editor makes changes in Child Version (logged to A and D tables). |
| |
| 2. RECONCILE: Child version pulls latest changes from Target (DEFAULT) Version. |
| System evaluates differences and checks for conflicts. |
| |
| 3. CONFLICT DETECTION: |
| • Conflict by Object (Row-Level): Same feature modified in both versions. |
| • Conflict by Attribute (Column-Level): Same column modified in both versions. |
| |
| 4. CONFLICT RESOLUTION: Conflicts resolved in favor of: |
| • Edit Version (Child) |
| • Target Version (DEFAULT) |
| • Manual Feature-by-Feature / Attribute-by-Attribute inspection. |
| |
| 5. POST: Resolved child edits are written directly into the Target (DEFAULT) |
| version state lineage. |
| |
| 6. COMPRESS: Database Administrator runs Geodatabase Compress to trim state tree, |
| collapse lineages, and push A/D delta records back to Base Table. |
+-----------------------------------------------------------------------------------+
1. Reconcile
When editing in a child version is complete, the editor initiates a Reconcile operation. Reconciling pulls all edits that have occurred in the target parent version (typically DEFAULT) into the active edit child version. This ensures that the child version is evaluated against the most current published state of the organization's data.
2. Conflict Detection Mechanisms
During reconciliation, the geodatabase identifies features that have been modified in both the child edit version and the target parent version since the child version was created. Conflicts can be evaluated at two distinct levels of granularity:
| Conflict Detection Method | Trigger Condition | Practical Behavioral Result |
|---|---|---|
| Conflict by Object<br/>(Row-Level Conflict) | A conflict is flagged if any attribute or the geometry of the same feature has been modified in both versions. | Highly conservative; flags a conflict even if Editor A changed only pipe_material while Editor B changed only install_date on the same pipe. |
| Conflict by Attribute<br/>(Column-Level Conflict) | A conflict is flagged only if the exact same attribute column (or the geometry) has been modified in both versions. | Allows non-overlapping field updates to merge automatically without raising a conflict (e.g., updates to pipe_material and install_date on the same feature merge seamlessly). |
3. Conflict Resolution
When conflicts arise, the editor can resolve them using three primary strategies:
- In Favor of the Edit Version: Overwrites the changes in DEFAULT with the child version's edits.
- In Favor of the Target Version (DEFAULT): Discards the child version's edits and retains the state currently in DEFAULT.
- Manual Resolution: The editor inspects each conflicting feature and field individually using an interactive conflict viewer, choosing on a field-by-field basis which values to accept.
4. Post
Following a successful reconcile and conflict resolution, the editor executes a Post operation. Posting pushes the child version's edits into the target version (DEFAULT), making them part of the authoritative corporate baseline.
5. The Geodatabase Compress Operation
As versioned editing proceeds across days and months, the database state tree accumulates thousands of branching states, and the Add (A) and Delete (D) tables grow to contain millions of records. This causes severe query performance degradation because every spatial query must join multiple massive delta tables.
The Compress Operation is an administrative maintenance routine executed by the geodatabase administrator. Its functions are:
- To remove unreferenced database states and dead branches from the state tree.
- To collapse linear state lineages into single common states.
- To move all rows from the Add and Delete tables that are common to all versions back into the Base Table.
BEFORE COMPRESS AFTER FULL COMPRESS
(Bloated State Tree) (State 0 Baseline)
State 0 (Base) State 0 (Base)
| | (Delta records moved
State 1 All Versions directly to Base)
/ \ Point to State 0
State 2 State 3 A & D Tables Empty
| |
State 4 State 5
[!IMPORTANT] A geodatabase cannot achieve a full compress to State 0 if any child versions remain unposted or active in the database. To achieve a 100% full compress to State 0, all child versions must be reconciled, posted to DEFAULT, and deleted before running the compress operation.
Branch Versioning: Modern Service-Based Architecture
While Traditional Versioning served enterprise GIS for decades, it was architected for desktop-based direct database connections (LAN environments). Modern enterprise workflows require editing spatial data across the web, on mobile devices (e.g., ArcGIS Field Maps), and through cloud-native REST APIs.
To meet this need, Branch Versioning was introduced as the core versioning engine for ArcGIS Enterprise and modern Utility Networks.
Key Architectural Distinctions: Traditional vs. Branch Versioning
+-----------------------------------------------------------------------------------+
| TRADITIONAL VERSIONING | BRANCH VERSIONING |
+---------------------------------------+-------------------------------------------+
| • Direct database connect (SQL / ArcSDE)| • Web service-based architecture (REST) |
| • Desktop GIS focused (LAN) | • Web GIS, Portal, Mobile, Cloud-native |
| • Multi-table Delta architecture | • Single physical Base Table |
| (Base Table + A Table + D Table) | (No A or D delta tables!) |
| • State Tree with State IDs | • System tracking: GDB_FROM_DATE, |
| • Requires periodic Compress routines | GDB_BRANCH_ID, GDB_IS_DELETE |
| • Complex, slow delta table joins | • Zero delta bloat; NO compress needed |
| • Reconcile/Post requires DBMS lock | • Fast, instant Reconcile & Post |
+---------------------------------------+-------------------------------------------+
How Branch Versioning Operates
Branch Versioning completely eliminates the Add (A) and Delete (D) delta tables. Instead, all edits are written directly into the single physical base table, managed by system tracking columns:
GDB_FROM_DATE: A system-maintained timestamp associated with the branch row.GDB_BRANCH_ID: The identifier of the version branch associated with the edit.GDB_IS_DELETE: A system flag indicating a deletion.- Additional deletion and archive identifiers may be maintained by the platform.
GDB_TO_DATEbelongs to classic geodatabase archiving rather than this branch-version row model.
Because all data resides in a single table indexed by timestamps, Branch Versioning never requires a Compress operation to maintain query performance.
Temporal Data Fundamentals
Temporal information can describe an instant (one timestamp), an interval (start and end), a recurring event, a changing state, a snapshot, or a trajectory. A sound schema distinguishes when a fact is true in the world (valid time) from when the database stores or knows it (transaction time). A bitemporal design stores both, allowing questions such as “What did the database report on March 1 about a closure valid in February?”
Temporal joins match records whose instants or intervals satisfy relationships such as before, after, overlaps, contains, or during. Define interval boundaries consistently—closed, open, or half-open—to avoid double counting events exactly on a boundary. Snapshot tables simplify as-of queries but duplicate unchanged state; event and history tables preserve change efficiently but require reconstruction. Trajectory analysis additionally needs ordered positions, timestamps, sampling awareness, and treatment of gaps.
Geodatabase Archiving & Historical Tracking
Geodatabase Archiving provides built-in mechanisms to capture, preserve, and query historical changes across the lifespan of geospatial assets.
How Archiving Works
When archiving is enabled on a feature class:
- The system creates an associated Archive Class (often designated with an
_Hsuffix in the underlying database) containing the identical schema as the base feature class, plus system date columns:GDB_FROM_DATEandGDB_TO_DATE. - When a feature is inserted, its
GDB_FROM_DATEis set to the current UTC timestamp, andGDB_TO_DATEis set to infinity (9999-12-31). - When a feature is updated or deleted, the active record is retired by stamping
GDB_TO_DATEwith the current timestamp, and the newly updated feature is inserted with a freshGDB_FROM_DATE.
Historical Markers and Temporal Queries
Geodatabase archiving enables instantaneous temporal analysis:
- Historical Markers: Named temporal milestones defined by the GIS administrator (e.g.,
"Tax_Year_2024_Certified","Pre_Storm_Baseline_Aug10"). Users can switch their map view to an historical marker to view and query the spatial database exactly as it existed at that moment. - Historical Range Queries: Analysts can query the database using SQL temporal clauses (such as
AS OF TIMESTAMP) or desktop time sliders to perform retrospective change detection, audit land parcel splits, or demonstrate regulatory compliance.
Summary of Common Exam Traps
[!CAUTION] Exam Trap 14.4.1: Believing That Posting Edits Automatically Clears Delta Tables. A widespread misconception is that reconciling and posting edits from a child version to DEFAULT clears the delta tables. This is false! Reconciling and posting merely updates state pointers. The Add (A) and Delete (D) tables will continue to grow indefinitely until a Geodatabase Administrator explicitly executes a Compress operation.
[!CAUTION] Exam Trap 14.4.2: Conflict by Attribute Does Not Eliminate All Conflicts. While "Conflict by Attribute" prevents conflicts when two editors modify different columns on the same feature, it does NOT eliminate conflicts when two editors modify the same column to different values, or when both editors modify the feature's geometry. In those instances, a conflict is still raised.
[!CAUTION] Exam Trap 14.4.3: Registering with "Move Edits to Base" Breaks Advanced Geodatabase Models. Registering a feature class as versioned with the option to move edits to base allows non-GIS third-party SQL applications to see edits immediately in the base table. However, doing so disallows all child versions (all editing must occur directly in DEFAULT) and prohibits participation in geodatabase topologies, utility networks, and archiving.
A county GIS department notices that spatial query performance and map service rendering speeds have degraded significantly over the past six months in their enterprise geodatabase. The database contains several active editing projects that use traditional versioning. What administrative procedure should the GIS Database Administrator perform to resolve this performance degradation?
In an enterprise geodatabase using traditional versioning, Editor A and Editor B both check out child versions from DEFAULT. Editor A changes the material attribute of water pipe #501 from 'Cast Iron' to 'Ductile Iron'. Simultaneously, Editor B changes the install_date attribute of water pipe #501 from '1975' to '1982'. If the geodatabase reconciliation rule is set to 'Conflict by Attribute', what will occur when Editor B reconciles against DEFAULT after Editor A has posted?
A state transportation department is transitioning its GIS infrastructure to modern web GIS services and mobile field editing applications running over REST APIs. They require a versioning architecture that does not require delta tables (A and D tables), eliminates the need for periodic compress operations, and logs all feature edits in a single physical base table using system timestamps. Which geodatabase architecture fulfills these requirements?