Deploying and Maintaining a Multiuser Geodatabase: The Working Guide

Search “deploying and maintaining a multiuser geodatabase” and page one is entirely course catalogue. Every result is the Esri training course of that name, or a reseller of it. There is almost no free written explainer of what the course title promises. This is that explainer.

An enterprise geodatabase is not a file geodatabase with more users bolted on. It is a set of system tables and behaviours layered on top of a commercial RDBMS — SQL Server, PostgreSQL, or Oracle — that adds multi-editor concurrency, versioning, and long transactions to a database that wasn’t designed for them. Most of the pain teams hit later is a consequence of decisions made at deployment: the versioning model, the privilege structure, and whether anyone owns the maintenance routine. This guide walks the deployment in order, then the maintenance work that keeps it from degrading.

The mechanics here are ArcGIS-specific because that is what “enterprise geodatabase” means in practice. They are also public knowledge — documented behaviour, not vendor secrets. Where numbers appear, they are reported practitioner anecdotes, flagged as such, not benchmarks.

The architecture: three tiers, and where it breaks

An enterprise geodatabase deployment has three tiers.

The RDBMS — SQL Server, PostgreSQL/PostGIS, or Oracle — holds the data and the geodatabase system tables. This is the tier that actually stores your features.
The connection tier — either a direct connection from the client to the database, or a service-based connection through ArcGIS Server / Enterprise. Which one you use is not a small detail. Branch versioning, covered below, only edits through a feature service. Traditional versioning can edit over a direct database connection.
The client tier — ArcGIS Pro for authoring and admin, web and mobile clients for the rest.

The failure most teams don’t anticipate lives at the connection tier. A direct-connect deployment is simple and fast for a small editing team. But the moment you want web editing, offline sync, or branch versioning, you need the server tier, and that tier becomes a dependency for editing to happen at all. Practitioners moving to branch versioning frequently balk at exactly this: if Portal or Server is down, editing stops, because there is no direct-database path to the versioned data. That is a real constraint, not a misconfiguration. Decide early which tier your editing depends on, because it dictates your uptime requirements.

Choosing the RDBMS

You get three realistic choices as the backing store. The geodatabase behaviour is broadly the same across all three; the operational differences are what matter.

SQL Server is the common default for utility and municipal deployments on Windows estates. Practitioners consistently cite easier backup and point-in-time recovery than PostgreSQL, and tighter integration with existing Windows/AD infrastructure. If your organisation already runs SQL Server for other systems, this is the path of least resistance.

PostgreSQL with PostGIS is the open option, and increasingly the default where licensing cost drives the decision. It is a capable enterprise-geodatabase backend and the backbone of QGIS and GeoServer stacks. The trap: ArcGIS and native PostGIS do not agree on geometry. ArcGIS stores curves in an extra binary column that other PostGIS clients cannot read, so a layer that round-trips cleanly through ArcGIS can appear broken to QGIS, and native PostGIS curves can defeat ArcGIS. If you want the same PostGIS database to serve both ArcGIS and open-source clients natively, plan for geometry that both sides can read — often meaning densified segments rather than true curves. We cover the PostGIS-as-datastore decision in more depth in PostGIS Setup for Network & Infrastructure Data.

Oracle remains the choice for the largest utilities and carriers, usually because Oracle is already the enterprise standard, not because of a GIS-specific advantage. It scales, but it brings Oracle’s operational weight and licensing.

There is no universally correct answer. Pick on the estate you already run, the licensing you can sustain, and — critically — your team’s ability to administer it. An enterprise geodatabase on an RDBMS nobody in-house can tune is a slow-motion incident.

Connecting and loading data

Once the RDBMS is stood up, you enable the geodatabase (this creates the SDE system tables) and connect from ArcGIS Pro as the geodatabase administrator. From there the real work is loading data and getting the ownership right the first time.

Two rules save you the most rework:

Load before you version. Register a dataset as versioned only after the bulk load is done. Bulk-loading into an already-versioned dataset pushes every insert through the delta tables (the A and D tables described below), which is slow and immediately bloats the versioning machinery you haven’t even started using.

Get data ownership right. In an enterprise geodatabase, the user who creates a feature class owns it, and ownership is difficult to change afterwards — often meaning drop and reload. Decide the owning schema up front. A common pattern is a dedicated data-owner account that owns all feature classes, distinct from the editor accounts that connect day to day.

Migrations are where ownership and versioning decisions most often go wrong, because people load into the wrong schema or version too early under time pressure. If you’re loading a geodatabase as part of a platform move, the failure modes are worth reading first — see Challenges in GIS Data Migration, particularly the sections on versioning locks during load.

Roles and privileges

Enterprise geodatabase privileges resolve to three practical tiers, and the discipline is to grant the minimum each user needs.

Data owner — creates and owns the feature classes. Powerful; used sparingly, ideally not as a daily login.
Editor — SELECT, INSERT, UPDATE, DELETE on the feature classes they edit. Granted per dataset, not globally.
Read-only / viewer — SELECT only. Most of your organisation belongs here.

Coarse access control is the pitfall. Granting every editor full rights across every dataset feels efficient and produces a slow accumulation of data-quality damage that nobody can attribute later, because there is no meaningful separation of who could touch what. Match the grant to the operational role. Where the RDBMS supports it, tie geodatabase roles to your corporate directory (AD/LDAP) so that joiners and leavers are handled in one place rather than as a manual geodatabase chore.

Privileges also interact with versioning. In branch versioning, editing runs through a feature service under the service identity, which changes where you enforce access — at the service and Portal sharing level as much as at the database grant. Design the two together.

Versioning: traditional vs branch

This is the decision that most confuses practitioners, and the one hardest to reverse. Get it right at deployment.

Both models let multiple editors work against isolated versions and reconcile their changes back to a default version. The mechanics differ fundamentally.

Traditional versioning stores edits in delta tables — an A (adds) table and a D (deletes) table — layered over the base tables. A query against a version reconstructs the current state by combining the base rows with the relevant delta rows. It supports direct database connections, so editors can work in ArcGIS Pro without a server tier. The cost is machinery: views, and (depending on the registration option) stored procedures, plus a compress operation that must be run regularly to keep the delta tables from growing unbounded. Traditional versioning is mature, flexible, and works without ArcGIS Server — but it carries ongoing maintenance overhead, and its performance degrades as the delta tables bloat.

Branch versioning is the newer model and is required for the ArcGIS Utility Network and other service-based workflows. Editing is service-based: you edit only through a feature service, via Portal or Server, never over a direct database connection. Branch versioning avoids the traditional model’s views/stored-procedure overhead and the classic compress cycle, and practitioners who have moved to it report better performance at scale for that reason. The trade-off is the hard dependency on Portal and Server. If they’re down, editing stops, because there is no direct-database editing path. Teams accustomed to direct connections find this genuinely uncomfortable, and it is the single most common objection to branch versioning.

A decision guide:

Choose branch versioning if you are deploying the Utility Network, you want web and offline editing, you can run and keep ArcGIS Enterprise available, and you want to avoid the traditional compress/delta-table treadmill. This is the forward-looking default for new deployments.
Choose traditional versioning if you need direct-database editing without a server dependency, you’re on an existing workflow that isn’t moving to the Utility Network, or your uptime model can’t guarantee Portal/Server availability during editing hours.
Do not run a feature class both ways or convert casually between them. Register the model deliberately and build your maintenance and access design around it.

The honest summary: branch is where the platform is heading and it removes a class of maintenance pain, but it substitutes an availability dependency. Traditional is the known quantity with a known, ongoing tax. Pick against your uptime reality, not the marketing.

Maintenance: the routine that keeps it fast

An enterprise geodatabase that runs beautifully at go-live and crawls six months later almost always has an absent or broken maintenance routine. Four jobs matter.

Compress (traditional versioning)

Compress moves rows from the delta tables into the base tables and removes states that are no longer referenced by any version. Run regularly, it keeps the delta tables small and queries fast. Skipped, the delta tables bloat and every versioned query slows.

The specific failure to know about: compress cannot always reach state 0. A full compress that collapses the version tree to a single state requires that no active connection or service is holding a geodatabase or RDBMS lock. In a live system there is always something connected — a running feature service, an open ArcGIS Pro session, a scheduled job. Practitioners repeatedly discover that to compress fully they must stop all services and disconnect all users first. The practical routine is a maintenance window: reconcile and post outstanding versions, delete unneeded versions, disconnect all users, stop the services, then compress. A compress run while editors are connected will only partially collapse the tree and leaves you wondering why the delta tables never shrink.

Locks and ERROR 999999

Compress and other admin operations fail when locks are held on the objects they touch. Most of the time those locks are legitimate — someone is connected. Sometimes they are orphaned: a client crashed, a connection dropped uncleanly, and the geodatabase still believes a lock is held.

The symptom is a compress that fails with the generic ERROR 999999. The cause is often stale rows in the geodatabase lock tables — SDE_state_locks and SDE_table_locks — that no longer correspond to a live session in SDE_process_information. The fix, done carefully and only when you have confirmed the sessions are genuinely dead, is to remove the orphaned lock rows so the operation can proceed. Confirm against SDE_process_information first; deleting locks that belong to a live editor will corrupt their session. This is a known, recurring failure, and knowing the three tables involved turns a mystifying ERROR 999999 into a five-minute fix.

Indexes

Spatial and attribute indexes drift as data changes. Under heavy editing, indexes fragment and query planners make worse choices. Rebuild spatial indexes on heavily edited feature classes on a schedule, and maintain the attribute indexes that your common queries and joins actually use. A feature class that has taken months of edits without an index rebuild is a common, quiet cause of “it just got slow.”

Statistics

The RDBMS optimiser chooses query plans from table statistics. After a large load, a compress, or heavy editing, those statistics go stale and the optimiser starts picking bad plans — the same query that was instant becomes a table scan. Update statistics as a standard step after compress and after any bulk change. This is cheap, it is easy to forget, and forgetting it is one of the most common reasons a geodatabase degrades for no visible reason.

A workable cadence for a traditional-versioned system: reconcile/post and compress in a regular maintenance window (weekly or monthly depending on edit volume), rebuild indexes and update statistics immediately after each compress, and keep an eye on delta-table row counts as your early-warning metric. Branch-versioned systems skip the compress cycle but still need index and statistics maintenance.

Troubleshooting performance degradation

When an enterprise geodatabase slows down, the causes cluster into a short list. Work them in order.

Delta-table bloat (traditional versioning). The first suspect. If the A and D delta tables have grown large, every versioned query is doing more work to reconstruct state. Check whether compress has actually been reaching a low state count; if it hasn’t — usually because it can’t reach state 0 with users connected — you have found it. Run a full compress in a proper maintenance window, then rebuild indexes and update statistics. Practitioners report that unmanaged versioning is the single most common driver of gradual slowdown.

Stale statistics and fragmented indexes. The second suspect, and often the real cause behind “it was fine yesterday.” A query plan that flipped from an index seek to a scan after a bulk change will feel like a systemic slowdown. Update statistics and rebuild indexes before you go looking for anything more exotic.

Network latency. Enterprise geodatabase traffic is chatty. Over a VPN or a high-latency link, that chattiness compounds, and a database that is fast on the LAN feels broken remotely. If slowness correlates with remote or VPN users specifically, the database is likely fine and the network is the problem. One practitioner reported a field-calculate on roughly 990,000 Oracle records taking 18–20 minutes — the kind of operation where round-trip count and link latency dominate, and where the fix is running the work closer to the database rather than tuning the database itself.

Service throughput, not the database. When the slowness is in a web feature service rather than in ArcGIS Pro, the bottleneck is often the service tier, not the RDBMS. Practitioners have reported ~2-million-record polygon layers staying slow through a feature service even after correct GIST/BTREE indexing on PostGIS — with the constraint identified as service throughput, not PostgreSQL. Check the database directly (a raw query in the RDBMS) before you blame it; if the raw query is fast and the service is slow, tune the service, not the geodatabase.

The diagnostic discipline: separate the tiers. Is the raw database query slow, or only the service? Only remote users, or everyone? Before compress, or after? Each answer eliminates a suspect. The teams that struggle are the ones that treat “it’s slow” as one problem instead of four.

The short version

Deploying a multiuser geodatabase is a sequence of decisions that are cheap to make correctly at the start and expensive to reverse later. Pick the RDBMS on the estate and skills you actually have. Load before you version and fix data ownership up front. Choose the versioning model against your uptime reality — branch for the Utility Network and web editing if you can keep Enterprise available, traditional where you need direct-database editing. Then own the maintenance routine: compress in a real maintenance window, know that it can’t reach state 0 with users connected, keep the three lock tables in mind when ERROR 999999 appears, and update statistics and rebuild indexes every time.

None of this is secret. It is documented behaviour that the course catalogue charges to explain and that nobody, until now, wrote down for free.

GIS as the Operational Layer for Utility and Telecom Networks — the pillar this sits under.
Challenges in GIS Data Migration — versioning locks and ownership traps when loading data into the geodatabase.
PostGIS Setup for Network & Infrastructure Data — the open-datastore option in depth, including the ArcGIS/PostGIS geometry trap.

LayerSpec designs and deploys multi-user geodatabases — architecture, versioning strategy, access control, and the maintenance routine that keeps them fast.

Informational content, not implementation advice. Enterprise geodatabase mechanics described here are public, documented behaviour; test any lock-table or compress operation against your own system before running it in production.