The Customer Challenge

A large utility organization managing critical geospatial infrastructure came to AWS with a familiar problem: their on-premises SQL Server environment was approaching end-of-support, and the path forward wasn't clear. Their situation:

• 500GB+ of geospatial data across multiple ArcGIS Enterprise deployments
• SQL Server Standard edition nearing end-of-life
• Escalating licensing costs with each upgrade cycle
• Growing concern about long-term vendor lock-in
• Team expertise centered on SQL Server and Esri tools

Their question: "Should we lift-and-shift SQL Server to AWS, or is this the right time to modernize to PostgreSQL?" This is the conversation we're seeing repeatedly across energy, utilities, and public sector organizations. The answer isn't one-size-fits-all, but there's a clear methodology for working through it. This post walks through the decision framework we used with this customer — the options, the trade-offs, and the key findings that emerged.

Why This Decision Matters Now

SQL Server has been the default database for ArcGIS Enterprise for decades. It's familiar, well-documented, and fully certified by Esri. But three forces are converging to make this decision more urgent:

1. Licensing Cost Trajectory SQL Server licensing costs compound with every instance, every environment, every read replica. As geospatial workloads scale, licensing becomes the dominant cost driver — often 60-70% of total database spend.

2. Upgrade Cycle Friction Every SQL Server major version upgrade requires planning, testing, downtime, and risk management. Organizations are tired of this cycle repeating every 3-5 years.

3. PostgreSQL + PostGIS Maturity PostgreSQL with the PostGIS extension has reached production-grade maturity for geospatial workloads. Esri now certifies PostgreSQL for ArcGIS Enterprise, and the ecosystem has caught up.

The core question isn't "Can we move to PostgreSQL?" — it's "What's the right path for our specific situation?"

The Six Options We Evaluated

We analyzed six deployment paths, ranging from minimal-change SQL Server migrations to full PostgreSQL modernization:

SQL Server Paths

Option 1: EC2 SQL Server (Self-Managed) Lift-and-shift to EC2 with license-included AMI. Maximum control, maximum operational burden. Monthly Cost: ~$720-750 Best For: Teams with existing automation and capacity to manage all operations

Option 2: RDS SQL Server Standard (Fully Managed) AWS-managed SQL Server with automated backups, patching, and upgrades. No OS access. Monthly Cost: ~$553-580 Best For: Managed SQL Server with zero operational overhead ⚠️ ArcGIS Enterprise Compatibility Note: Standard RDS SQL Server does not provide OS-level access, which is typically required by Esri's enterprise geodatabase configuration process. Most ArcGIS Enterprise deployments cannot use this option. Confirm compatibility with Esri before proceeding.

Option 3: RDS Custom for SQL Server (Managed with OS Access) Managed SQL Server that retains OS-level access for customizations. Supports ArcGIS Enterprise geodatabase requirements. Monthly Cost: ~$575-620 Best For: ArcGIS Enterprise workloads requiring managed SQL Server with OS access

PostgreSQL Paths

Option 4: RDS PostgreSQL Single-AZ Fully managed open-source PostgreSQL with PostGIS extension. No licensing cost. Monthly Cost: ~$316 Best For: Cost reduction, licensing freedom, application-layer HA

Option 5: RDS PostgreSQL Multi-AZ Same as Option 4 with automatic failover to standby instance in second Availability Zone. Monthly Cost: ~$633 Best For: Production-grade database-layer HA with long-term cost optimization

Option 6: Amazon Aurora PostgreSQL AWS-native PostgreSQL-compatible engine with cloud-native performance and availability features. Monthly Cost: ~$330 Best For: Performance-critical workloads, multiple read replicas, rapid scaling ⚠️ Aurora Fast Clone Limitation: While Esri certifies Aurora PostgreSQL for ArcGIS Enterprise, Aurora's fast clone feature (copy-on-write cloning) has not been tested by Esri and does not work reliably with ArcGIS geodatabases. If fast cloning is a requirement, use standard RDS PostgreSQL instead.

Cost Comparison: The Numbers Tell a Story

Here's the 3-year total cost of ownership comparison at on-demand rates:

| Option | | Monthly Cost | 3-Year TCO (On-Demand) | 3-Year TCO (Reserved) |

| EC2 SQL Server | ~$720-750 | ~$27,000 | ~$10,800-11,500 |

| RDS SQL Server Standard |~$553-580 | ~$20,900 | ~$8,400-9,000 |

| RDS Custom SQL Server | ~$575-620 | ~$21,600-22,300 | ~$8,600-9,200 |

| RDS PostgreSQL Single-AZ | ~$316 | ~$11,400 | ~$4,600-5,000 |

| RDS PostgreSQL Multi-AZ | ~$633 | ~$22,800 | ~$9,200-9,600 |

| Aurora PostgreSQL | ~$330 | ~$11,900 | ~$4,800-5,200 |

Key Finding: PostgreSQL is approximately 45% less expensive than SQL Server on single-instance deployments and 40% less expensive on equivalent multi-instance high-availability deployments. This gap widens as you scale — every additional instance, read replica, or dev/test environment carries the same licensing overhead on SQL Server.

Decision Framework: Which Path is Right?

Here's the decision tree we used with this customer:

START: What are your primary requirements?

 ├─ Running ArcGIS Enterprise geodatabase?
 │  ├─ YES → Must stay on SQL Server?
 │  │  ├─ YES → Need managed service?
 │  │  │  ├─ YES → **Option 3: RDS Custom SQL Server** (OS access required)
 │  │  │  └─ NO → **Option 1: EC2 SQL Server**
 │  │  └─ NO → Confirm PostgreSQL compatibility with your ArcGIS version
 │  │     └─ **Option 4/5/6: PostgreSQL** (based on HA/performance needs)
 │  └─ NO → Continue
 │
 ├─ Primary driver is cost reduction and future-proofing?
 │  ├─ YES → Need database-layer HA?
 │  │  ├─ YES → Need cloud-native performance features?
 │  │  │  ├─ YES → **Option 6: Aurora PostgreSQL** (avoid fast clone)
 │  │  │  └─ NO → **Option 5: RDS PostgreSQL Multi-AZ**
 │  │  └─ NO → **Option 4: RDS PostgreSQL Single-AZ**
 │  └─ NO → Continue
 │
 ├─ Want fully managed with zero operational overhead?
 │  ├─ YES → Must stay on SQL Server?
 │  │  ├─ YES → Confirm no OS access needed
 │  │  │  └─ **Option 2: RDS SQL Server Standard** (not for ArcGIS Enterprise)
 │  │  └─ NO → **Option 4/5/6: PostgreSQL**
 │  └─ NO → **Option 1: EC2 SQL Server** (maximum control)

Key Findings: What We Learned

1. SQL Server Licensing is the Dominant Cost Driver

The cost gap between SQL Server and PostgreSQL is almost entirely licensing, not compute or storage. This compounds as environments scale. For the customer's projected growth (3 production instances, 2 dev/test, 5 read replicas over 3 years), PostgreSQL would save approximately $85,000-95,000 compared to SQL Server.

2. RDS Custom Fills a Specific Gap for ArcGIS Enterprise

For customers who cannot move to standard RDS due to ArcGIS Enterprise geodatabase requirements, RDS Custom provides OS-level access while maintaining AWS-managed automation. This is the recommended managed SQL Server path for ArcGIS workloads. However, it carries meaningfully higher operational responsibility than standard RDS and does not materially reduce cost compared to Option 2. Select it only when OS access is a confirmed requirement.

3. PostgreSQL + PostGIS is Production-Ready for Geospatial Workloads

Esri now certifies PostgreSQL for ArcGIS Enterprise, and PostGIS provides robust geospatial capabilities. The ecosystem has matured significantly:

• Spatial indexing: GiST and SP-GiST indexes for efficient spatial queries
• Geometry types: Full OGC Simple Features support
• Spatial functions: 400+ functions for spatial analysis, transformation, and measurement
• Raster support: PostGIS Raster for raster data storage and analysis

The learning curve is real, but manageable. AWS provides no-cost PostgreSQL Immersion Day training (hands-on, half-day, facilitated by AWS) to close the familiarity gap.

4. Aurora PostgreSQL Offers Cloud-Native Performance — With Caveats

Aurora PostgreSQL provides up to 3x the throughput of standard PostgreSQL with automatic storage scaling, fast cloning, and up to 15 read replicas — at only ~$15-20/month more than standard RDS PostgreSQL. However: Esri certifies Aurora PostgreSQL for ArcGIS Enterprise but did not test Aurora's fast clone feature specifically. Fast clone does not work reliably with ArcGIS geodatabases. If fast cloning is a requirement, use standard RDS PostgreSQL (Options 4 or 5) instead.

5. Migration Complexity is Manageable — With the Right Tools

AWS Schema Conversion Tool (SCT) automates schema translation from SQL Server to PostgreSQL and identifies incompatibilities early. AWS Database Migration Service (DMS) enables live migration with minimal downtime. ⚠️ DMS Spatial Data Limitation: AWS DMS does not currently support SQL Server spatial data types or PostGIS spatial data migration. It only supports one Oracle spatial type. This is a known gap with no near-term fix. For geospatial workloads, you must use alternative migration approaches:

• Native PostgreSQL tools: pg_dump/pg_restore with custom scripts for spatial data
• Esri tools: ArcGIS Data Interoperability extension or FME for spatial ETL
• Third-party tools: Safe Software FME, GeoKettle, or custom Python scripts using ogr2ogr

Migration Timeline Expectations:

• SQL Server to SQL Server (Options 1-3): 2-4 weeks (backup/restore, compatibility validation)
• SQL Server to PostgreSQL (Options 4-6): 6-12 weeks (schema conversion, spatial data migration, application testing, team training)

6. The Right Time to Modernize is Before You're Forced To

Customers who wait until SQL Server end-of-support are forced into reactive decisions with compressed timelines. The best time to evaluate PostgreSQL is when you have time to plan, train, and test properly.

What the Customer is Exploring

This customer is now actively exploring PostgreSQL for their next-generation geospatial platform. They haven't made a final decision yet, but here's their current thinking: Short-Term (Next 6 Months):

• Migrate one non-critical ArcGIS Enterprise environment to RDS PostgreSQL Single-AZ (Option 4) as a pilot
• Complete AWS PostgreSQL Immersion Day training for the core team
• Validate application compatibility and performance against production workload patterns
• Test spatial data migration approaches using native PostgreSQL tools and Esri Data Interoperability

Medium-Term (6-18 Months):

• If pilot succeeds, migrate production ArcGIS Enterprise environments to RDS PostgreSQL Multi-AZ (Option 5)
• Migrate remaining SQL Server workloads to RDS Custom SQL Server (Option 3) as an interim bridge
• Develop PostgreSQL expertise across the broader team

Long-Term (18+ Months):

• Evaluate Aurora PostgreSQL (Option 6) for performance-critical workloads once Esri testing catches up
• Eliminate SQL Server licensing costs entirely
• Establish PostgreSQL as the standard for all new geospatial projects

Key Success Factors:

• Executive sponsorship for the learning curve investment

• Dedicated pilot environment with production-like workload patterns

• Clear success criteria defined upfront (performance, cost, operational overhead)

• Phased approach that doesn't force a "big bang" migration

Recommended Next Steps

If you're evaluating SQL Server vs PostgreSQL for geospatial workloads, here's the playbook:

1/ Validate Your ArcGIS Compatibility Confirm your ArcGIS Enterprise version against the Esri PostgreSQL compatibility matrix. Not all versions support PostgreSQL equally. Engage Esri support early to confirm supportability.

2/ Understand Your Customization Requirements Determine whether your workloads require OS-level access (custom CLR assemblies, linked servers, third-party agents). This is the gate between standard RDS and RDS Custom for SQL Server paths.

3/ Schedule PostgreSQL Immersion Day AWS provides no-cost, hands-on PostgreSQL training facilitated by AWS. This closes the familiarity gap before you commit to a path. Contact your AWS account team to schedule.

4/ Pilot Before You Commit Select a non-critical database for pilot migration. Validate performance, application compatibility, and spatial data migration approaches before committing production workloads.

5/ Plan for Spatial Data Migration Since AWS DMS doesn't support spatial data migration, plan alternative approaches using native PostgreSQL tools, Esri Data Interoperability, or third-party ETL tools.

6/ Apply Reserved Pricing On-demand pricing is useful for comparison, but Reserved Instances reduce compute costs by ~35% (1-year) or ~60% (3-year). Compute Savings Plans can provide up to 60-70% savings with greater flexibility.

The Bottom Line

PostgreSQL + PostGIS is production-ready for geospatial workloads. It eliminates licensing costs, future-proofs your database platform, and provides robust geospatial capabilities through PostGIS. SQL Server still makes sense when:

• ArcGIS Enterprise geodatabase requirements demand OS access and you need managed service (RDS Custom)
• Team capacity for PostgreSQL learning curve doesn't exist
• Application dependencies on SQL Server-specific features cannot be refactored

But for most organizations, the question isn't "if" — it's "when." The best time to evaluate PostgreSQL is when you have time to plan, train, and test properly, not when you're forced into a reactive decision by end-of-support deadlines.

Join the Conversation

This is the inaugural post for the AWS re:Post Geospatial Community. Starting April 2026, AWS Solutions Architects supporting energy, utilities, and public sector customers will actively direct geospatial questions here. Have questions about PostgreSQL for geospatial workloads? Post them here. Migrated from SQL Server to PostgreSQL? Share your experience. Found a better approach to spatial data migration? We want to hear about it. This community exists to scale practical, opinionated guidance for geospatial workloads on AWS — the kind of content that doesn't fit in formal documentation but solves real customer problems. Let's build this together.

Additional Resources

• AWS Pricing Calculator: https://calculator.aws/
• AWS Schema Conversion Tool (SCT): https://aws.amazon.com/dms/schema-conversion-tool/
• Esri ArcGIS Enterprise System Requirements: https://enterprise.arcgis.com/en/system-requirements/
• PostGIS Documentation: https://postgis.net/documentation/
• RDS Custom for SQL Server: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-setup-sqlserver.html
• Amazon Aurora PostgreSQL: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraPostgreSQL.html
• ArcGIS Test Study for a Network Information Management System Electric Utility (PostgreSQL): https://amzn-aws.slack.com/archives/D09FQ11L1NG/p1775238724712309?thread_ts=1774975734.378869&cid=D09FQ11L1NG
• ArcGIS Test Study for a Network Information Management System Gas Utility (SQL Server): https://architecture.arcgis.com/en/architectures/network-management-gas-sqlserver/introduction.html

Contact your AWS Solutions Architect or Account Manager to get started.

Pricing reflects US East (N. Virginia) on-demand rates as of March 2026. Reserved Instance and Savings Plans pricing can reduce costs by 35-70%. All figures are estimates and should be validated in the AWS Pricing Calculator. Esri ArcGIS compatibility should be confirmed against current Esri documentation prior to platform selection.