When to use an enterprise geodatabase versus file geodatabases

It is generally recommended that you use an enterprise geodatabase to maintain the source data for your 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 (DBA) to optimize, tune, and maintain the enterprise geodatabase.

If your organization does not have a DBA on staff and your published data is relatively static, using a file geodatabase may be a good alternative. File geodatabases generally provide great performance without needing extra configuration or tuning. Depending on the characteristics of the GIS data, in some cases, extra optimization and tuning of an enterprise geodatabase might be required to surpass the performance of a file geodatabase.

In map and globe caching workflows where 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, you should place an identical copy of the file geodatabase on each GIS server machine. For example, in an ArcGIS Server site with three GIS servers, each GIS server should access its own copy of the file geodatabase. The GIS servers should not access the same 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, in scenarios where 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. Releasing the geodatabase can be done by stopping the service or, for multiple-machine sites, by temporarily removing the GIS server machines from the site, then 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 the many calls to the enterprise geodatabase that would need to occur across the network. This can lighten the load on your database and speed up the 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.