System storage is a foundational requirement of ArcGIS Enterprise to support administrative and other workflows in the organization. Included in this storage requirement are two relational stores that support hosted feature data and administrative aspects, such as customization and configuration settings.
An administrator may configure persistent volumes to support the relational stores, or alternatively, they may configure the relational store outside of the cluster using a supported cloud database service. This option may be best for administrators with experience administering PostgreSQL databases, as it can provide reliability, scaling, and performance advantages when using cloud services from AWS, Azure, and Google Cloud.
Considerations for using a cloud relational store with ArcGIS Enterprise—including software usage, supported types, requirements, and ongoing maintenance needs—are provided below.
Supported cloud database services
The following cloud database service types are supported for use with ArcGIS Enterprise on Kubernetes:
- Amazon RDS for PostgreSQL
- Amazon Aurora PostgreSQL
- Azure Database for PostgreSQL - Flexible Server
- Google Cloud SQL for PostgreSQL
- Google Cloud AlloyDB for PostgreSQL
Database requirements
At this software release, a cloud relational store configured with ArcGIS Enterprise on Kubernetes must meet the following requirements:
- The database version must be 15.
- The database must be network accessible from the Kubernetes cluster. Consider that some security groups and firewalls may block direct access to the database by default.
- The database username and password authentication must be used for the administrator account.
- You must install the PostGIS plug-in and enable the PostGIS spatial type. This is the default for AWS and Google Cloud and is optional for Azure.
Connections and instance sizing
It is important to consider and allocate for sufficient sizing of your database instance, as many services do not allow instance resizing. Additionally, resizing an instance after its been in use may be disruptive or lead to unforeseen issues.
Consider that each database connection consumes memory and CPU on the database servers and impacts hardware needs.
For example, a pod that is running for a hosted feature service may use up to 100 database connections when there are 100 simultaneous requests. Since it is typical to have two running pods for hosted feature services, 200 connections must be available. To account for other service requests, an additional 100 are recommended, for a total of 300.
When possible, hosted feature service pods use pooling to re-use connections. As a result, 300 connections may be enough to handle up to 1,000 requests per second. The default for most cloud databases is typically fewer than 300 connections, so it is recommended that you increase the connection limit to 300 or more.
Databases use RAM to improve performance on frequently accessed data. Hosted feature services typically contribute the largest amount of data. Usage can vary considerably since many services may be used infrequently, while others may be accessed constantly. If you know that some hosted feature services will be accessed consistently and you can estimate their size, it may be worthwhile to plan for additional RAM.
Hardware recommendations
For solid performance with a median load, it is recommended to use database instances with the following:
- 4 virtual CPUs
- 16 GB RAM
For larger data volumes that are frequently accessed, it is recommended to add more RAM.
Storage considerations
Your organization's storage needs will vary depending on the data you're using. A baseline recommendation may be 100 GB of storage, which may be suitable for a few hundred hosted feature services with minimal attachments. Feature attachments, especially high-resolution imagery, can consume exceedingly large amounts of space. If you anticipate having large attachments, it's essential that you work with your GIS department to estimate the storage space, as some organizations exceed 1 TB of storage to support their data needs.
Software usage
When configuring a cloud relational store, consider that its resulting database is to be used exclusively for ArcGIS Enterprise on Kubernetes. It is recommended that no other databases or data exist in that database. Additionally, the software creates databases, schemas, and users in the database, including the following:
- An enterprise geodatabase to store hosted feature service data
- A database to store information about content and items
- A database to store webhook information
The administrative database user that you provide to ArcGIS Enterprise is used during initial configuration and the backup and restore processes. Specific least-privilege users will be created for operational use, ensuring greater security.
Ongoing maintenance
When using a cloud relational store, your IT or database administrator must continue the ongoing maintenance and management of the system. The following are examples:
- Manage the database system by applying patches and monitoring hardware use, particularly storage
- Manage system-wide settings such as the number of connections
ArcGIS Enterprise software, on the other hand, continues ongoing software maintenance. The following are examples:
- Back up and restore the database during routine organization backup and restore processes
- Manage columns, tables, indices, and users
Administrators can create their own database backups, but it's essential that you consult with Esri Technical Support before restoring a database backup in isolation, as doing so may cause synchronization issues with other foundational requirements, such as the object store.