Where your data resides significantly impacts your workflow within ArcGIS Pro.

If you’re reading this article then you’re likely experiencing some sort of lag, or latency, when working with a sde database connection in ArcGIS Pro, or when working with other data, such as a file geodatabase (gdb), over a network file share. So let’s try to make sense of it.

ArcGIS Pro is a “thick” client, which means that it is a software application that performs most of its processing locally instead of sending actions to a remote server to perform the work server side. Therefore, Pro truly shines when the data it’s working with is also local.

When working with database connections or .sde file connections, Pro performs best the closer it is – physically/geographically – to the relational database management system (RDBMS) where the sde, or enterprise gdbis housed. So if you’re working on the east coast, but your RDBMS is on the west coast, then you’re probably experiencing some slowness. We also see this same database latency with ArcGIS Pros installed locally on laptops/desktops and making direct database connections to cloud-hosted providers such as AWS/Azure/Google.

Aside from the database latency, it also matters what kind of hardware on which Pro is installed. Pro has some serious system requirements, and I do not recommend doing production work on the minimum specs. The recommended specs are a 4-core CPU, 32 GB of RAM, and a discrete, not integrated, GPU with 4 GB of dedicated memory. The optimal specs are at least a 10 core CPU, 64GB of RAM, and the same 4GB GPU. Pro performs very well on gaming PCs. With that said, let’s dive into some options to alleviate the latency.

Database Connections

If someone needs to edit data via a direct connection to the database in order to prevent latency, there are a few options.

Virtual Machine/Remote Desktop

One option is running ArcGIS Pro from a VM (virtual machine), or physical machine, in the same region, or datacenter, as the database server and performing work there.

For instance, while it’s technically possible to connect to an enterprise geodatabase in an Amazon RDS or EC2 instance from an on-premises ArcGIS Pro installation, this is not recommended. This setup often leads to slower performance and is discouraged by Esri. For optimal performance, it’s best to connect using an ArcGIS Pro installation on an EC2 instance or workspace within the same AWS region where the relational database management system (RDBMS) is hosted. This approach minimizes latency.

Though the example mentioned AWS, this applies to all databases hosted by other cloud providers as well. Below are some common practices we see with some GEO Jobe clients.

Check-Out/Check-In Replication

Create a “Check-out/Check-in” replica. This replication works by allowing a database administrator to create a child replica (check-out) from data on the enterprise database so that the user can perform their work locally on their desktop/laptop.

Then, once the user is done, the edits can be synchronized (checked-in) with the enterprise gdb. Once the synchronization is done, the checkout replica (child) is then deleted and can no longer be used for future updates, so if any time additional edits are required, then a new check-out is needed.

Edit via REST

If you have ArcGIS Enterprise then you can edit data via the REST services in ArcGIS Pro. This entails just using the REST URL in your Project and then editing the data as if it were a feature class. However, this has to be done carefully to not cause conflicts.

Since everyone could be potentially editing the same “version,” depending how the enterprise gdb is configured and how the services are published, it’s possible for users to edit the same data at the same time. Which can cause conflicts. To make this option viable, you would establish an operating procedure that makes sense for your organization.

Branch Versioning

Another option is branch versioning, which is a vigorous REST service editing workflow. Branch versioning is a framework where multiple editors can work simultaneously on a single feature class in a highly isolated fashion without creating copies of the data that simultaneously tracks changes made to a database.

This brings the ability to test new designs internally without affecting published data, the capability to monitor data evolution over time and support project workflows implemented across many organizations. Using branch versioning requires more administrative management but would help with latency by forcing users to perform their edits on their own versions through the REST services.

More information on setting up branch versioning and the level of effort can be found in the next section. This is not a common workflow, and we usually don’t recommend branch versioning unless it fits perfectly for what the clients needs are.

Final Recommendation

Shift users over to working with ArcGIS Enterprise services, if possible. In many ways, services look and perform the same to end users in Pro, and most lightweight users can do their duties via Portal web maps and applications. Users working with the Enterprise gdb directly should be minimized. Those users who need to make direct connections will need to be “close” to where the Enterprise gdb is housed.

If the data is on a cloud provider, then Pro users needing to make direct database connections would need to remote onto VDIs, Workstations, VMs, etc, within the same region as the data, and conduct their ArcGIS Pro workflows there.

I didn’t really speak to this, but just like Pro, Enterprise needs the data sources for its services to be close. So I don’t recommend moving data away from Enterprise to reduce connection lag in Pro. The less checkpoints between Pro or Enterprise, and the data, the more performant they’ll be.

Additionally, please read these slides from an Esri workshop session, particularly starting on slide 9, as they strongly correlate to database/data connections latency issues.

Hope you find this useful and that it helps improve your productivity, but most of all, decreases your stress level.

Encountering database latency issues or need assistance optimizing your ArcGIS Pro and Enterprise workflows? Don’t hesitate to reach out to our team via connect@geo-jobe.com for expert guidance and solutions tailored to your specific needs. We’re here to help you enhance your productivity and reduce stress related to data connectivity and more.

**Like this article? Explore these others from our MapThis! blog:**

About Our Company

GEO Jobe is a leading GIS software and geospatial solutions provider, serving over 10,000 organizations globally. GEO Jobe is best known for developing the most popular applications in the ArcGIS Marketplace, including Admin Tools for ArcGIS, Backup My Org, Clean My Org and Scheduler for ArcGIS.

GEO Jobe offers U.S.-based 24/7 Support solutions for organizations using Esri’s ArcGIS© System. GEO Jobe also offers professional services focused on Esri’s ArcGIS© System, including custom software development, enterprise solution implementation, data science and UAV data collection.

Founded in 1999, GEO Jobe is in its 25th year of operation, has been an Esri business partner since 2002 and is currently a Platinum Partner.

ArcGIS Pro: Critical Considerations for Storing Your Data