---
title: Test Study for a Parcel Management System (SQL Server)
description: Test study for a Parcel Management System in Azure on SQL Server
content_type: test-studies
source_url: "https://architecture.arcgis.com/en/architectures/parcel-management-sqlserver/physical-architecture.html"
md_url: "https://architecture.arcgis.com/en/architectures/parcel-management-sqlserver/physical-architecture.md"
---
# Physical architecture

This architecture was evaluated in January 2026 with:
- A medium-sized parcel management organization in mind
- Support for parcel management workflows, with a target design load as described in the [test methods](/en/architectures/parcel-management-sqlserver/test-results.md) section
- An enterprise geodatabase configured with SQL Server
- Microsoft Azure cloud infrastructure

The system was designed for and tested against the specified workflows, with adjustments to the machine types and sizes as needed based on test results.


![Physical architecture for a Parcel Management System: (SQL Server)](https://architecture.arcgis.com/assets/images/test-studies/PMS_architecture.svg "Physical architecture for a Parcel Management System: (SQL Server)")

_Download a [Microsoft Visio file](/assets/diagrams/PMS_architecture.vsdx) of this architecture._
_Learn more about [diagramming resources](/en/framework/architecture-practices/diagramming-resources.md) for ArcGIS systems._

> [!NOTE]
> **Note**
> For more information on the software components and key interactions in this architecture, review the Land Information Management System [reference architecture](/en/architectures/parcel-management/introduction.md).
# Machine types and sizes

The following represent the machine sizes chosen and validated for the scope and purpose of this test study. However, it is highly recommended to follow a complete design process to account for your business and technical requirements.

Esri offers [system architecture design](https://www.esri.com/en-us/arcgis/services/consulting) services should you need help determining all of the different factors relating to your organization's physical design - such as networking, storage, system environments, and sizing. Minimum system requirements for each component are listed in the respective software [documentation available online](https://doc.arcgis.com/en/).

#### Desktop (ArcGIS Pro & web browser)

| Spec | Value |
|---|---|
| Machines | 3 |
| Standard_NC8as_T4_v3 | |
| CPU | 8 vCPU |
| RAM | 56 GB |
| GPU | 16 GB |
| Storage | 128 GB |


#### Portal for ArcGIS

| Spec | Value |
|---|---|
| Machines | 2 |
| Standard_D4s_v6 | |
| CPU | 4 vCPU |
| RAM | 16 GB |
| Storage | 128 GB |


> [!NOTE]
> **Note**
> For this test system, 2 cores was sufficient. However, Esri [highly recommends a minimum of 4 cores for production systems](https://enterprise.arcgis.com/en/system-requirements/latest/linux/portal-for-arcgis-system-requirements.htm#ESRI_SECTION1_80B50BEEF1CF42A99D8C164DAA51A3CE).
#### ArcGIS GIS Server

| Spec | Value |
|---|---|
| Machines | 2 |
| Standard_D8s_v6 | |
| CPU | 8 vCPU |
| RAM | 32 GB |
| Storage | 128 GB |


#### ArcGIS Server (hosting server)

| Spec | Value |
|---|---|
| Machines | 2 |
| Standard_D8s_v6 | |
| CPU | 8 vCPU |
| RAM | 32 GB |
| Storage | 128 GB |


#### ArcGIS Data Store (relational)

| Spec | Value |
|---|---|
| Machines | 2 |
| Standard_D4s_v6 | |
| CPU | 4 vCPU |
| RAM | 16 GB |
| Storage | 128 GB |


#### ArcGIS Web Adaptor

| Spec | Value |
|---|---|
| Machines | 2 |
| Standard_D2as_v6 | |
| CPU | 2 vCPU |
| RAM | 8 GB |
| Storage | 128 GB |


#### ArcGIS Monitor

| Spec | Value |
|---|---|
| Machines | 1 |
| Standard_D8s_v6 | |
| CPU | 8 vCPU |
| RAM | 32 GB |
| Storage | 128 GB |


#### File storage

- 1 instance
- NetApp Files
- 100 MiB/s throughput
- 1 TB Disk

#### Database

| Spec | Value |
|---|---|
| Machines | 1 |
| Standard_D16s_v6 | |
| CPU | 16 vCPU |
| RAM | 64 GB |
| Storage | 1 TB |


#### Directory Services

- Microsoft Entra Domain Services

# Additional infrastructure considerations

The following are additional areas of consideration when designing a Network Information Management System and an explanation of some infrastructure choices made for this test study.

To learn more about designing ArcGIS systems with Azure components and services, see [Azure technologies](/en/framework/architecture-pillars/integration/providers/microsoft.md#azure-technologies).

### Load balancing and reverse proxying

At least one third-party load balancer is required in a highly available ArcGIS Enterprise deployment - they handle client traffic to your portal and server sites and internal traffic between the software components. Although the ArcGIS Web Adaptor is considered a load balancer, it is insufficient on its own to serve as a load balancer in a [high availability](/en/framework/architecture-pillars/reliability/high-availability.md) configuration. Therefore, in this test study, Azure Application Gateway was used.

### Database considerations

For the scope and purposes of this test study, a choice was made to deploy SQL Server on a virtual machine. However, depending on your needs, you might consider leveraging a database platform service like [Azure SQL Managed Instance](https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/sql-managed-instance-paas-overview?view=azuresql) in a Microsoft Azure environment.

### Shared storage

To successfully implement a highly available ArcGIS Enterprise deployment, the configuration stores must be stored in a highly available, shared location. This ensures this data remains accessible even if one server fails, providing uninterrupted service to end-users. Additionally, shared storage simplifies data management in a multi-machine deployment and improves scalability by centralizing data storage and allowing for expansion as needed. In this test study, Azure NetApp Files was used.

### System components not included in the diagram

Note that while antivirus software and Azure networking components are not illustrated in this diagram, they were present in the test study.