Skip to main content

User storage

ArcGIS Enterprise supports configuring web services that reference user data, as an alternative to copying the data to ArcGIS Enterprise during publishing. When ArcGIS Enterprise is running in the cloud, additional data storage options become available to support referenced web layers. These include cloud storage, managed database services, and cloud data warehouses.

The options available will depend on the type of web service you are publishing as well as the environment where ArcGIS Enterprise is deployed.

You can register a user data store by adding a data store item in the organization, by using ArcGIS Pro, or directly with an ArcGIS Server site by using Server Manager.

Databases

You can register databases with ArcGIS Server, which allows you to publish services that reference data in those databases. These might be databases that you install and maintain, such as relational, document, or graph databases. The databases might also be cloud database services or cloud data warehouses.

Databases you install and maintain

For both on-premises and cloud deployments, you can use a register a database you have installed and configured outside of ArcGIS. Several different database management systems are compatible with ArcGIS, but each system has different requirements you must meet. See Supported databases and data warehouses for more information.

Database services

For cloud deployments, cloud vendors provide Databases as a Service (DBaaS) that allow you to use database systems without the need to install, upgrade, or maintain the underlying software and hardware. These services also provide significant benefits in terms of manageability and scalability. ArcGIS supports various DBaaS solutions, including support for storing enterprise geodatabases in them. This can be an alternative to installing a relational database management system (RDBMS) such as Microsoft SQL Server, Oracle, or PostgreSQL on a virtual machine (VM) in the cloud.

For the list of supported database service offerings, see the requirements for using ArcGIS with databases in the cloud.

Cloud data warehouses

Cloud data warehouses are scalable, resilient, and performant solutions for storage that are available in public clouds as managed services. Cloud data warehouses are optimized for analytics on large volumes of data and are increasingly used as a centralized repository for data storage. ArcGIS Enterprise supports integrating data from cloud data warehouses for visualization and analysis.

See Requirements for using ArcGIS with databases in the cloud for more information about supported cloud data warehouses for use with ArcGIS Enterprise and ArcGIS Pro.

Folders

For both on-premises and cloud deployments, you can register folders that contain GIS resources, such as imagery data. A folder can be local to the ArcGIS Server machine or a network share. Local folders generally enable faster data access, but if the ArcGIS Server machine with the local data is unavailable, you also lose access to the data. For that reason, it is recommended to use a network share for multiple-machine ArcGIS Server sites.

Cloud stores

For cloud deployments, you can use a cloud store to store the data and caches for referenced web layers. The types of layers and the cloud storage services that are supported vary by workflow, but you can read more about them by following the links below.

Cloud stores can be registered as data stores with ArcGIS Server and used in the following ways:

  • Store prerendered cached tile images for map services or image services configured to draw from a cache. Using cloud data stores as cache directories is an alternative to storing large caches on your file system.

  • Store prerendered caches for tile, vector tile, 3D tiles, or scene layers. Caches will be created and placed in the registered cloud storage location, with referenced services being published directly from the data store item in ArcGIS Enterprise. This approach saves time while publishing large datasets and avoids using resources on the hosting server, relative to the alternative of copying all data while publishing from ArcGIS Pro.

  • Store raster and image files that can be used to publish referenced imagery layers. This is supported when ArcGIS Enterprise is configured for image hosting or raster analysis.

Latency considerations for cloud services integration

Using cloud services for user data creates the potential for latency that can negatively impact performance. For example, registering a cloud data warehouse running in a cloud provider's Eastern US region with an ArcGIS Server site running on-premises in an Australian data center will require requests for data to travel a long distance over the network. Services that are published using that data will be slow to respond to requests.

To minimize latency, it is recommended that you co-locate components in the same region of the same cloud provider. Co-location reduces the distance information needs to travel across the network. For example, if you are using Amazon S3 in the AWS af-south-1 region to store imagery for your referenced imagery layers, all of the other components of ArcGIS Enterprise should also be running in the AWS af-south-1 region. Clients that publish services to ArcGIS Enterprise, such as ArcGIS Pro, should also be co-located with ArcGIS Enterprise.

Note:

Esri does not formally support connecting to cloud services for referenced data if ArcGIS Enterprise software components are not running in the same region of the same cloud.

Database considerations for publishing services

When deploying an ArcGIS Server site, you need to choose where to place the source data for your web services. This topic discusses some appropriate scenarios for using enterprise geodatabases and file geodatabases.

When to use an enterprise geodatabase versus a file geodatabase

It is generally recommended that you use an enterprise geodatabase to maintain the source data for your map and feature services. An enterprise geodatabase offers high-availability support, backup and recovery, concurrency, scalability, and a tendency to provide superior throughput. However, this recommendation is provided with the assumption that your organization has a dedicated database administrator to optimize, tune, and maintain the database.

If your organization does not have a database administrator on staff and your published data is relatively static, using a file geodatabase may be a good alternative. File geodatabases generally provide good performance without needing extra configuration or tuning. Depending on the characteristics of the GIS data, a file geodatabase may perform better than an enterprise geodatabase if the database the enterprise geodatabase is stored in is not optimized and maintained.

In map and globe caching workflows for which many read-only calls are being made to the data in rapid succession, file geodatabases accessed through local paths often perform better than enterprise geodatabases.

Before you choose to use a file geodatabase, remember that some functionality of enterprise geodatabases, such as versioning, geodatabase replication, and historical archiving, are not available in file geodatabases. Also, standard database management system capabilities, such as logging, backup and recovery, and failover configuration, are not available in file geodatabases.

Considerations for file geodatabases

When you use a file geodatabase as a data source, place an identical copy of the file geodatabase on each ArcGIS Server machine. For example, in an ArcGIS Server site with three machines, each machine must access its own copy of the file geodatabase. Do not configure the ArcGIS Server site to access a single file geodatabase over the network.

This configuration minimizes network communication traffic among the different ArcGIS Server components and reduces I/O contention when accessing the file geodatabases. Factors that influence potential disk I/O contention for a shared file geodatabase include the number of layers in the map service, the nature of the data in the file geodatabase, and the file storage device.

File geodatabases are intended for read-only use with ArcGIS Server. Because of this, you cannot publish feature services that reference data in a file geodatabase. Also, in scenarios in which the file geodatabase is a publication geodatabase (in one-way replication workflows), replica synchronization needs to occur during periods of inactivity in the map service or by releasing the file geodatabase from being used by the map service. You can release the geodatabase by stopping the service or, for multiple-machine sites, by temporarily removing the ArcGIS Server machines from the site, and reconnecting them after the file geodatabase has been updated.

ArcGIS Server cannot disable schema locking on file geodatabases.

File geodatabases and map caching

File geodatabases work well for map caching scenarios. By placing an identical file geodatabase on each machine working on the cache, you can eliminate multiple calls to the enterprise geodatabase that would need to occur across the network. This can lighten the load on your database and speed up caching.

You can use one-way replication from an enterprise geodatabase to create these file geodatabases. You can even replicate into the projection of the map that will be cached. A common example is caching a web map in the WGS 1984 Web Mercator (Auxiliary Sphere) projection used by ArcGIS Online, Bing Maps, and Google Maps. This is not usually a recommended projection for storing your datasets in an enterprise geodatabase, but it is a good projection for caching a web map from a file geodatabase.