Multi-user geodatabase design

Multi-user geodatabase design is the architecture that lets a GIS team actually work concurrently — multiple editors, audit trail, version control, no overwriting each other’s changes by accident. The work that turns “we’ll all share this shapefile on the network drive” into something that scales.

We design and deploy multi-user geodatabases on the platform that fits the client. Geospatial work is delivered through our partner Geodars.

Why this is its own discipline

Single-user GIS workflows handle a handful of editors with informal coordination. Multi-user breaks at predictable points:

• Concurrent editing collisions — two people edit the same feature at the same time; one set of edits gets silently overwritten
• No audit trail — when something goes wrong, no record of who changed what when
• Backup as a manual process — backups happen when someone remembers; restoring is rare and untested
• Performance under load — workflows that worked for one user crawl with ten
• Access control absent or coarse — everyone can edit everything, or no one can do anything

A multi-user geodatabase is the architecture that solves these systematically rather than by hoping people are careful.

Platform options

Esri SDE (Enterprise Geodatabase) — for organisations on the ESRI stack. Mature versioning model, deep ArcGIS integration, multi-user editing through ArcGIS Pro and Web GIS.

PostGIS-based multi-user — for open-source environments. Multi-user editing supported through PostgreSQL’s transactional model; versioning typically built application-side rather than via a built-in versioning model.

Esri Utility Network on SDE — for utilities specifically; topology and traceability features that generic geodatabases don’t provide.

Hybrid — many real organisations have data in both ESRI and PostGIS, with controlled flows between them.

The right choice depends on the organisation’s wider technology posture, operational team capability, and licence model. We assess at the start.

What’s in a multi-user geodatabase delivery

A complete deployment covers:

Architecture

• Database server setup (cloud or on-premises)
• Schema design with multi-user concurrency in mind
• Versioning model — branched, traditional ArcGIS versioning, or application-level

Access control

• User and group management
• Role-based permissions (read, edit, admin)
• Feature-class-level or row-level controls where needed
• Integration with corporate directory (LDAP, AD, SSO)

Concurrent editing

• Conflict detection and resolution
• Audit logging — who changed what when
• Edit session management

Operational layer

• Backup with tested restore
• Replication for high availability or read-scale
• Monitoring and alerting
• Documentation for admins and editors

Performance tuning

• Indexes appropriate to query patterns
• Connection pooling configuration
• Workload-specific tuning where concurrent loads are high

Inputs we need

A productive engagement runs on:

• Team size and growth expectation — number of concurrent editors today and projected
• Data volumes — feature counts, expected growth
• Existing platform context — what’s in use today, what’s being moved away from
• Performance requirements — uptime, recovery, response time expectations
• Security requirements — access control granularity, audit requirements, regulatory drivers
• Integration points — what other systems need to connect

Common pitfalls in outsourced geodatabase work

Concurrent editing assumed to “just work”. Multi-user editing without an explicit conflict-handling strategy produces silent data loss. We design the conflict resolution model up front and document how editors handle conflicts.

Versioning skipped or minimal. Geodatabases without proper versioning produce environments where rolling back a bad edit is essentially impossible. We design versioning in, not on.

Backup untested. Backups that have never been restored are not backups. We test restore as part of deployment.

Access control too coarse. Granting every editor full edit rights produces eventual data quality disasters. We design role-based access matched to operational reality.

Performance reactive. Tuning that happens only after queries are slow accumulates operational debt. We tune for known query patterns at design time.

Typical timelines

• Small team deployment (under 10 editors, single dataset) — 4-8 weeks
• Mid-sized team (10-50 editors, multiple datasets, integration work) — 8-16 weeks
• Enterprise deployment with HA, replication, complex integrations — 16-32 weeks

How we deliver

Geospatial work runs through our partner Geodars. The team has direct experience with multi-user geodatabases on ESRI and PostGIS, including utility, telecom, and asset-management deployments.

Talk to us about a geodatabase project

Tell us the team size, the platform direction, and the operational context. We’ll scope and price for the project. Larger or HA-focused deployments warrant a scoping call.