Postgres Upgrade Service

Service Overview 

EDB mitigates the risks associated with database upgrades—including downtime, data loss, and performance degradation—by providing a comprehensive service that covers planning, testing, execution, and verification. Our tiered offerings ensure you only pay for the complexity you have, with transparent pricing and defined timelines.

Service Tiers

We offer three distinct packages based on the complexity of your PostgreSQL Cluster*. 

*A Cluster is defined as a Primary Server and up to 3 additional Standby Servers. Each server in the cluster contains one Postgres Instance. An Instance is defined as a single running database service (PID) on a specific port.

Scope of Services

The following scope is included in all tiers:

Phase 1: Discovery & Planning

• Initial workshop to understand business requirements and technical landscape.
• Comprehensive pre-upgrade assessment of the current environment, and identification of any breaking changes on the database level only. 
• Analysis of pg_upgrade compatibility and potential differences between versions
• Creation of a detailed, step-by-step Upgrade Plan document.
• Development of a formal Rollback Plan.

Phase 2: Testing & Validation

• Full run of the upgrade process in a dedicated staging environment.
  • UAT environment should be as similar in data volume and complexity as possible. 
• Remediation of existing data corruption or catalog inconsistencies discovered during the Discovery phase.
• Use of appropriate upgrade methods (pg_upgrade, logical replication, etc.) to meet downtime requirements.

Phase 3: Execution & Verification

• Execution of the planned production upgrade with certified PostgreSQL specialists on hand via screenshare
• Running of ANALYZE and other maintenance tasks on the new version
• Completion of post-upgrade verification and formal transition to EDB Support

Deliverables

In support of the engagement, EDB team will provide the following documents:

• Upgrade Runbook: Step-by-step plan to execute upgrade, including post migration validation and a formal Rollback Plan. The document will also include recommended configuration changes based on the pre-upgrade assessment.

Key Exclusions:

• Application Code Remediation: Modifying application code or SQL queries to be compatible with the new PostgreSQL version is not included. We can provide a report of incompatible queries as a separate service.
• Infrastructure Provisioning: Costs and management of hardware, virtual machines, or cloud infrastructure.
• Operating System (OS) Upgrades: The underlying OS is expected to be compatible with the target PostgreSQL version.
• Third-Party Tool Configuration: Upgrading or reconfiguring external tools like connection poolers (e.g., PgBouncer), backup software, or monitoring agents.
• Extensive Performance Tuning: In-depth query optimization or performance tuning beyond post-upgrade validation is available as a separate engagement. While EDB will run ANALYZE, exhaustive tuning of SQL execution plans that change due to version-specific optimizer updates is excluded
• High Availability Deployment: Deployments for high availability with EDB supported tools can be purchased with other EDB packaged services 

Roles and Responsibilities

EDB Project Manager:  Responsible for initial planning, task alignment, and project closeout.

EDB Solution Architect: Technical Lead, responsible for Upgrade design validation.

EDB Senior Consultant: Execution lead, responsible for upgrade testing, validation,documentation and availability for go-live.

Customer Team: Responsible for providing the main point of contact for the existing instance requirements. Resources and Roles (or similar Technical Stakeholders) where input may be needed for the engagement include:

• System Architect
• Database Administrator
• Infrastructure Manager 
• Network Administrator
• Application Owner

Customer’s application SMEs and business SMEs are responsible for all application code/program changes, integration, user acceptance testing, and performance testing.

Assumptions

• A project kickoff will be conducted to review the service scope and confirm the schedule
• This service is delivered remotely unless otherwise agreed
• EDB Lasso Tool is required for the Upgrade and is available through the EDB support portal. 
• Customer will provide the names, title, email, phone number, and area of responsibility of those participating. One person will be designated as the main contact, and will be able to provide access to the people most knowledgeable about the topics to be discussed or examined. 
• Customer will make appropriate personnel available to assist EDB in the performance of the services as needed and requested by EDB in a timely manner so as not to disrupt the project schedule. 
• Customer will not provide Personal Data (as defined in applicable law). Customer agrees that it will work with EnterpriseDB to ensure that all such data is not provided.  
• Customer is responsible for providing all necessary internal design and project related documentation where EDB is required to analyze, operate, or modify customer implemented systems.
• Customer will ensure timely access to all systems through screen sharing and experts including third parties as required. 
• Customer will assign the appropriate resources with the appropriate privileges for the task being planned for any screen sharing sessions as needed throughout the engagement.
• A Cluster is defined as a Primary Server and up to 3 additional Standby Servers. Each server in the cluster contains one Postgres Instance. An Instance is defined as a single running database service (PID) on a specific port..
• EDB will support the Upgrade of one (1) Cluster  in one (1) non-production environment, and oversee execution in one (1) production environment. Additional environments may require additional packages and cost. 
• For the large Tier: Near-zero downtime is subject to technical compatibility (e.g., presence of Primary Keys, lack of unsupported data types). If Logical Replication is not viable, a standard downtime window using pg_upgrade will be required."

Prerequisites

• Customer will provide appropriate EDB Lasso Tool output for the proposed instance
• Customer will provide resource availability for testing planning, access or screen sharing for systems as required, and a point of contact for coordination.
• Customer is responsible for providing all necessary internal design and project related documentation and requirements where EDB is required to analyze, operate, or modify customer implemented systems.
• Customer must ensure sufficient disk space is available for the upgrade method chosen.