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.