Data location considerations

ArcGIS Pro supports both local data, such as file or mobile geodatabases, and remote data, such as enterprise geodatabases or service data (web layers).

If only one user or process will access the data at a time, you can use data that is local to the client. However, in enterprise systems in which multiple users need access to the data, the data must be stored in a central location. That location will be remote from most users and clients who access it.

Remote data has unique demands. You must evaluate how this data is used when there are multiple users accessing it at one time. Data transfer between ArcGIS Pro and remote data sources is latency sensitive, and many small requests are made while viewing and editing data or working with and changing data schema. Unlike local data, which typically has a single user accessing it, long-running database queries affect all users of remote data. This means it is especially important to consider how maps are authored and used in ArcGIS Pro for remote data sources.

Tip:

This topic and its related links focus on patterns and practices specific to ArcGIS Pro. To learn about the recommended patterns and practices to design and implement entire ArcGIS systems, visit the ArcGIS Architecture Center.

Local data sources

Local data sources are those that are stored on the same machine where the client that accesses the data is running. Most local data sources—such as mobile geodatabases, Open Geospatial Consortium (OGC) GeoPackage files, file geodatabases, shapefiles, and SQLite databases—are not intended for use by more than one user at a time.

When data is accessed by one user from a client on the same machine where the data is stored, the network latency between the client and data source is low. In addition to low network latency, there is little to no contention between multiple users for access to local data. This means that all available resources can be dedicated to a single client, and locking or other such mechanisms enforced by the data source do not cause a delay with data retrieval.

Remote data sources

Remote data sources are those that do not run on the same machine as the client accessing it. All cloud data warehouses and most relational databases fall into this category. How remote the client is from the data—in other words, how physically removed the data is from the client—will affect the amount of time it takes to send queries between the client and the data. For example, using ArcGIS Pro on your local machine and network to access data in a database that is running on a machine in the server room in your building will likely not be as slow as using your local installation to access a database in the cloud.

Learn more about how data and ArcGIS Pro locations can affect performance

Network latency is significantly higher for remote data sources than local data sources, and the speed and throughput of your network also affect performance.

When you access remote data using slower transfer protocols and hardware (for example, HTTP), the data needs to travel further at slower transfer speeds. While this latency is rarely the underlying cause of performance or scalability concerns, remote data source-based workflows are more sensitive to high-frequency or large-sized data access requests. In multiuser environments, the data server is a resource or set of resources that is shared by multiple users at the same time. You must take into account the actions of all users of the system when designing maps and workflows. Data access requests can overwhelm even a well-architected system if techniques are not used to reduce the volume of total requests and size of requests when possible.

Learn more about configuring projects, maps, and layers to use remote data