Skip Navigation
Show nav
Heroku Dev Center Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
Heroku Dev Center Dev Center
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log in or Sign up
View categories

Categories

  • Heroku Architecture
    • Compute (Dynos)
      • Dyno Management
      • Dyno Concepts
      • Dyno Behavior
      • Dyno Reference
      • Dyno Troubleshooting
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
    • Buildpacks
  • Developer Tools
    • Command Line
    • Heroku VS Code Extension
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery & Integration (Heroku Flow)
    • Continuous Integration
  • Language Support
    • Node.js
      • Node.js Behavior in Heroku
      • Troubleshooting Node.js Apps
      • Working with Node.js
    • Ruby
      • Rails Support
        • Working with Rails
      • Working with Bundler
      • Working with Ruby
      • Ruby Behavior in Heroku
      • Troubleshooting Ruby Apps
    • Python
      • Working with Python
      • Background Jobs in Python
      • Python Behavior in Heroku
      • Working with Django
    • Java
      • Java Behavior in Heroku
      • Working with Java
      • Working with Maven
      • Working with Spring Boot
      • Troubleshooting Java Apps
    • PHP
      • Working with PHP
      • PHP Behavior in Heroku
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
    • .NET
      • Working with .NET
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Getting Started
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
      • Migrating to Heroku Postgres
    • Heroku Key-Value Store
    • Apache Kafka on Heroku
    • Other Data Stores
  • AI
    • Working with AI
    • Heroku Inference
      • Inference API
      • Inference Essentials
      • AI Models
      • Heroku Inference Quick Start Guides
    • Tool Use
    • Vector Database
    • AI Integrations
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
      • Single Sign-on (SSO)
    • Private Spaces
      • Infrastructure Networking
    • Compliance
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Teams
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Integrating with Salesforce
    • Heroku AppLink
      • Getting Started with Heroku AppLink
      • Working with Heroku AppLink
      • Heroku AppLink Reference
    • Heroku Connect (Salesforce sync)
      • Heroku Connect Administration
      • Heroku Connect Reference
      • Heroku Connect Troubleshooting
    • Other Salesforce Integrations
  • Databases & Data Management
  • Heroku Postgres
  • Postgres Basics
  • Upgrading the Version of a Heroku Postgres Database

Upgrading the Version of a Heroku Postgres Database

English — 日本語に切り替える

Table of Contents [expand]

  • Upgrading with the Direct Upgrade Method
  • Upgrading with the Follower Failover Method
  • Upgrading with the Data Copy Method
  • Deprovisioning the Old Primary Database

Last updated October 22, 2025

This article describes how to upgrade the major Postgres version of a Heroku Postgres database. The most recent major Postgres version supported by Heroku is 17.

Users can’t update a database’s minor version themselves. If a new minor version is available and the database is on an older minor version, Heroku automatically updates the minor version after each database maintenance on Standard-tier and higher plans.

You can only upgrade your major Postgres version via the Heroku CLI. It’s a significant operation that you must do with care.

Heroku supports three methods for upgrading the Postgres version of your database. All methods require some application downtime to ensure that no data is lost during the upgrade.

Upgrade Method Description
Direct (recommended) Upgrades the version directly on your database by using pg:upgrade:* commands.

Works for all Heroku Postgres plans and is the recommended method.

Requires downtime of around 10 minutes for most use cases, although this amount can vary.
Follower Failover Upgrades the version by provisioning a follower of your database and using pg:upgrade:run on the follower. After the upgrade, the follower unfollows its parent database and becomes a fork on the target version.

Works for all Heroku Postgres plans except for Essential-tier plans.

Requires downtime of about 20–30 minutes for most use cases, although this amount can vary.
Data Copy Upgrades the version by provisioning a new database and copying data to the new database with pg:copy.

Only works for Essential, Standard, Premium, or Private-tier Heroku Postgres plans that are under 10 GB.

Not supported for Shield-tier plans because PGBackups don’t work with Shield databases.

Requires downtime of about 3 minutes per GB for most use cases, although this amount can vary substantially.

The upgrade methods in this article cover upgrading the database version of a Heroku Postgres database. Upgrading the version on a leader database through the Direct upgrade method automatically upgrades any follower databases. If you upgrade with the Follower Failover or Data Copy upgrade methods, you must create new follower databases after your new leader database is upgraded.

You can upgrade your database to versions 15, 16, and 17. Use the --version flag to specify the version to upgrade to. For example, add --version 16 to upgrade to Postgres 16. If you don’t set the --version flag, the upgrade defaults to the latest version.

 

The upgrade process can fail due to out-of-memory errors for databases with a large number of schemas. If your database has more than 1,000 schemas or stores more than 10,000 objects, test the upgrade in advance and open a Support ticket for assistance if the upgrade fails.

Upgrading with the Direct Upgrade Method

You can use the Direct upgrade method to perform version upgrades on Essential-tier databases and Standard-tier and higher leader databases. The Direct upgrade method differs depending on your database plan. Upgrades on Essential databases run immediately, while Standard-tier and higher databases follow a maintenance-like process.

This method upgrades the version of your database directly, maintaining your existing database add-on. Direct upgrades automatically control and restrict login access to the database while the upgrade is running to prevent lost writes. Access is restored after the upgrade completes.

You must be on Heroku CLI v10.8.0 or later to use these commands. Update the CLI version with heroku update.

Essential-Tier

We’re changing the pg:upgrade CLI command for Postgres version upgrades. You can still use pg:upgrade to upgrade the version of your Essential database until the command reaches end-of-life. We recommend using the new upgrade commands to upgrade your Postgres version. See this Help article for more details.

Direct upgrades on Essential-tier databases immediately upgrade your database version. This process transfers the data to a new database on the target Postgres version that replaces your existing database. Database access is restricted during the upgrade, and automatically restored after the upgrade completes. This upgrade method requires app downtime of around 10 minutes for most use cases, although this amount can vary depending on the data size of your database.

To upgrade the version on an Essential-tier database, run pg:upgrade:run directly on your database:

$ heroku pg:upgrade:run HEROKU_POSTGRESQL_RED --app example-app

By default, pg:upgrade:run updates your database to the latest supported version. You can specify a target version with the --version flag.

To monitor the upgrade progress, run pg:upgrade:wait:

$ heroku pg:upgrade:wait Heroku_POSTGRESQL_RED --app example-app
Waiting for database postgresql-crystalline-69217... Available

You receive separate email notifications when the version upgrade starts and after it’s complete.

Standard-Tier and Higher

Direct upgrades on Standard-tier and higher databases automate the Postgres major version upgrade of an existing database. You can schedule and run the upgrade similar to a Heroku Postgres database maintenance.

The upgrade commands use the PostgreSQL pg_upgrade utility to upgrade your Postgres version in-place. This upgrade method requires app downtime of around 10 minutes for most use cases. Database access is restricted when the upgrade starts, and automatically restored after the upgrade completes.

If your database has any followers, the followers are also automatically upgraded to the target version after your leader database is upgraded. Existing database followers remain operational during their parent database upgrade. After the leader database is upgraded, followers experience replication lag until they’re automatically replaced and upgraded to the target version. The followers can continue replicating from the upgraded leader.

To upgrade the major version on a Standard-tier and higher database:

  1. Run pg:upgrade:prepare to prepare your leader database for upgrade and schedule it during the next available maintenance window.
  2. Wait until the scheduled maintenance for the upgrade to start automatically, or run pg:upgrade:run to start the prepared upgrade at any time.

You can test the version upgrade beforehand with the pg:upgrade:dryrun command to verify your database’s schema and data are compatible with the new Postgres version. To test your app’s compatibility and performance with the new Postgres version, follow the Testing with a Forked Database instructions.

You can keep a copy of your database in the old version by forking the database or creating a follower database and unfollowing it before starting the upgrade with pg:upgrade:run.

1. Prepare Your Version Upgrade

It’s not necessary to prepare the version upgrade on Essential-tier databases because those databases upgrade immediately instead of through maintenance windows. To upgrade the Postgres version on an Essential database, see the Essential-Tier section.

To begin, run pg:upgrade:prepare on your leader database:

$ heroku pg:upgrade:prepare HEROKU_POSTGRESQL_RED --app example-app
Preparing upgrade on postgresql-crystalline-69217... done
Your database is scheduled for upgrade during your next available maintenance window.
Run heroku pg:upgrade:wait to track its status.
You can also run this upgrade manually before the maintenance window with heroku pg:upgrade:run. Note: You can only run the upgrade after it's fully prepared, which can take up to a day.

This command prepares the upgrade and schedules it for the next available maintenance window. Preparing the upgrade can take up to a day. You receive an email notification after the upgrade is prepared and scheduled. You can check the status of the upgrade preparation with pg:upgrade:wait or pg:info. For example, with pg:upgrade:wait:

$ heroku pg:upgrade:wait HEROKU_POSTGRESQL_RED --app example-app
Waiting for database postgresql-crystalline-69217... ⣟ preparing service for upgrade

You can cancel your prepared upgrade before the scheduled maintenance begins or before you start the upgrade with pg:upgrade:cancel.

2. Run Your Version Upgrade

During the upgrade, database connections are restricted and your app can’t access the database. If you use Heroku Connect to sync Salesforce data with your database, Heroku Connect can’t connect to your database during the upgrade. If any sync processes are impacted, your connection will be in the DB_UNAVAILABLE error state. You can recover your connection after the version upgrade is finished to resume synchronization. Or, you can pause your Heroku Connect connection before the upgrade starts to avoid the DB_UNAVAILABLE state.

After your upgrade is prepared and scheduled, you can either wait until the maintenance window for the upgrade to start automatically, or start the version upgrade manually on your leader database with the command pg:upgrade:run:

$ heroku pg:upgrade:run HEROKU_POSTGRESQL_RED --app example-app

After starting the upgrade, you can’t cancel it. The upgrade process restricts database access after the upgrade starts to prevent writes, and restores access after it completes. You receive an email notification after your database upgrade completes.

You can check the status of the running upgrade with pg:upgrade:wait:

$ heroku pg:upgrade:wait HEROKU_POSTGRESQL_RED --app example-app
Waiting for database postgresql-crystalline-69217... ⣟ (1/8) checking upgrade service

As part of the pg:upgrade:run process, Heroku Postgres runs ANALYZE on your database. This process recalculates statistics for your database to make sure the Postgres query planner has up-to-date information even after a version upgrade.

The pg:upgrade:run command can fail due to errors such as incompatible data types in a table in your database. If your upgrade fails, running pg:upgrade:wait or pg:wait returns version upgrade error, check your Heroku email notifications for details. In the case of errors during a Direct upgrade, the upgrade automatically cancels and restores access back to your database on the old version. You receive an email notification with the error details. You can prepare a new upgrade and try upgrading again after resolving the error.

If you paused your Heroku Connect connection, make sure you resume the Heroku Connect connection after the version upgrade is complete.

After the database upgrade is completed, this method automatically replaces any followers on your database and upgrades them to the target version. It takes some time to replace and upgrade all followers. The existing followers pending upgrade remain operational but experience replication lag until they’re replaced. You can verify the status and version of every follower with heroku pg:info.

$ heroku pg:upgrade:wait HEROKU_POSTGRESQL_RED --app example-app
Waiting for database postgresql-crystalline-69217... ⣟ (8/8) recreating followers in the new postgres version. Use `heroku pg:wait` to track its status.

$ heroku pg:info HEROKU_POSTGRESQL_PURPLE -a example-app
=== HEROKU_POSTGRESQL_PURPLE_URL

Plan:                  Standard 0
Status:                Recreating follower to follow the new leader
PG Version:            16.9
...
Following:             HEROKU_POSTGRESQL_RED

Upgrading with the Follower Failover Method

We’re changing the pg:upgrade CLI command for Postgres version upgrades. You can still use pg:upgrade to upgrade the version of your Essential database until the command reaches end-of-life. We recommend using the new upgrade commands to upgrade your Postgres version. See this Help article for more details.

Performing a version upgrade with the Follower Failover method involves upgrading a follower of your database and promoting it as your new, upgraded database. With this method, you perform the upgrade on a separate add-on and your old database remains available after the upgrade. During the upgrade process, you must put your app in maintenance mode and prevent any writes to your original database. The Follower Failover method requires app downtime on the order of 20-30 minutes, considering the upgrade time itself and the manual steps required.

If you must upgrade both the Postgres version and your plan, provision a new follower on a different plan and use pg:upgrade:run as part of the changeover process.

You can test the version upgrade using this method beforehand with a forked database.

If you use Heroku Connect to sync Salesforce data with your database, see the instructions for upgrading the Heroku Postgres database version with a follower database.

If you use Streaming Data Connectors, see the instructions for upgrading the Heroku Postgres database version with a follower database.

1. Provision a Follower Database

We recommend creating your upgrade target follower at least 24 hours in advance before running pg:upgrade:run.

To begin, create a follower for your database and wait for the follower to catch up to the leader database. You can provision the plan best suited for your needs.

The example creates a follower with a standard-2 plan for the HEROKU_POSTGRESQL_LAVENDER database. Replace HEROKU_POSTGRESQL_LAVENDER with the config var, attachment or add-on name of the leader database you’re upgrading.

$ heroku addons:create heroku-postgresql:standard-2 --app example-app -- --follow HEROKU_POSTGRESQL_LAVENDER
Adding heroku-postgresql:standard-2 to example-app... done, v71 ($200/mo)
Attached as HEROKU_POSTGRESQL_WHITE
Follower will become available for read-only queries when up-to-date
Use `heroku pg:wait` to track status

The follower is considered “caught up” when it is within 200 commits of the primary database. You can check how many commits the follower is behind with the pg:info command. See the Behind By row of the follower database:

$ heroku pg:info --app example-app
=== HEROKU_POSTGRESQL_LAVENDER
Plan:        Standard 0
Status:      available
...
=== HEROKU_POSTGRESQL_WHITE
Plan:        Standard 2
Status:      available
...
Following:   HEROKU_POSTGRESQL_LAVENDER (DATABASE_URL)
Behind By:   125 commits

2. Enter Maintenance Mode to Prevent Database Writes

It’s important that no new data is written to your current primary database during the upgrade process, because it doesn’t transfer to the new database when the follower starts upgrading. To accomplish this, place your app into maintenance mode. If you have scheduler jobs running as well, or other external systems connecting to the database, disable them. Databases continue to accrue billing hours while in maintenance mode.

Maintenance mode doesn’t automatically scale down dynos. Scale down web and any non-web dynos (for example, heroku ps:scale worker=0) to ensure that no connections are writing data to the database.

 

Your application is unavailable starting at this point in the upgrade process.

$ heroku maintenance:on --app example-app
Enabling maintenance mode for example-app... done

3. Upgrade the Follower Database

Now that you are in maintenance mode and no additional data is being written to the primary database, you can upgrade the follower database.

Wait for the follower database to fully catch up to the primary as indicated by being behind by 0 commits.

$ heroku pg:info --app example-app
=== HEROKU_POSTGRESQL_LAVENDER_URL
Plan:        Standard 0
Status:      available
...
=== HEROKU_POSTGRESQL_WHITE_URL
Plan:        Standard 2
Status:      available
...
Following:   HEROKU_POSTGRESQL_LAVENDER_URL (DATABASE_URL)
Behind By:   0 commits

If you don’t wait for the follower to catch up, then you get an error message when you start the upgrade:

 ▸    database is too far behind its leader. Wait until your follower catches up with its leader and try again.

When the follower is caught up, use the pg:upgrade:run command to upgrade the Postgres version of the follower in place. Upgrading also causes the follower to unfollow the primary database. This step usually requires about 20 minutes to complete.

$ heroku pg:upgrade:run HEROKU_POSTGRESQL_WHITE --app example-app

You can monitor the progress of the upgrade with pg:upgrade:wait or pg:wait:

$ heroku pg:upgrade:wait HEROKU_POSTGRESQL_WHITE --app example-app
Waiting for database HEROKU_POSTGRESQL_WHITE_URL... performing final cleanup steps after upgrade

As part of the pg:upgrade:run process, Heroku Postgres runs ANALYZE on your database. This process recalculates statistics for your database to make sure the Postgres query planner has up-to-date information even after a version upgrade. All credentials and custom credentials are also rotated as a part of the upgrade process.

The pg:upgrade:run command can fail due to errors such as incompatible data types in a table in your database. If your upgrade fails, you receive an email notification with the error details. Also, running pg:upgrade:wait or pg:wait returns version upgrade error, check your Heroku email notifications for details. In the case of any errors, deprovision the follower that failed to upgrade and retry the upgrade after resolving the error on your leader database.

4. Promote or Attach the New Database

If DATABASE_URL was the config var for your previous primary database, use pg:promote to promote the newly upgraded database as the new DATABASE_URL. pg:promote creates an alternate attachment for the old primary database, assigned with a new HEROKU_POSTGRESQL_<color>_URL config var. The promotion process triggers a release and restarts the app.

$ heroku pg:promote HEROKU_POSTGRESQL_WHITE --app example-app
Promoting HEROKU_POSTGRESQL_WHITE_URL to DATABASE_URL... done

Now the follower database you created in step 1 is the primary database (DATABASE_URL) for the app, although the app isn’t receiving new requests yet.

If the database you’re upgrading has a different config var other than the default DATABASE_URL, use heroku addons:attach to promote your newly upgraded database with the required alias or attachment name. If you attached your original primary database to multiple apps, you must attach your new upgraded database to those apps with addons:attach.

After the promotion, followers of your original primary database don’t automatically start to follow your new primary.

Create followers for the new primary database as needed:

$ heroku addons:create heroku-postgresql:standard-0 -a example-app -- --follow DATABASE_URL

Be sure to deprovision your old followers after you no longer need them.

 

If your old primary was using connection pooling, and it was attached with the default name DATABASE_CONNECTION_POOL, pg:promote reattaches the connection pooler to the new primary under the same name DATABASE_CONNECTION_POOL.

Attachments under non-default names aren’t reattached. You must activate connection pooling on your new primary if you wish to keep using connection pooling on your new primary with the same non-default name as the old primary:

$ heroku pg:connection-pooling:attach DATABASE_URL --as MY_DATABASE_CONNECTION_POOL -a example-app

5. Exit Maintenance Mode

To resume normal application operation, scale any non-web dynos back to their original levels (for example, heroku ps:scale worker=1).

Finally, turn off maintenance mode:

$ heroku maintenance:off --app example-app

Your application is now receiving requests to your upgraded database instance. You can confirm this by running heroku pg:info. The database denoted by DATABASE_URL is considered the primary database.

If your Heroku Postgres database isn’t connected to a Heroku app, you must retrieve the connection string of the upgraded database. Then update your application and any external systems to point them to the new, upgraded database.

Upgrading with the Data Copy Method

Performing a version upgrade with the Data Copy version upgrade method involves copying the data from your database to a new database that’s on the target version. When the data copy completes, you can promote the database on the target version and start using it as your new primary database. During the data copy process, you must put your app in maintenance mode to prevent any writes to your original database.

The Data Copy upgrade method uses native PostgreSQL backup and restore utilities to transfer your data to a newly provisioned database. This process helps reduce bloat, the extra space taken up by dead rows on your database, and can save disk space.

This method requires approximately 3 minutes of app downtime per GB of your current database, although this amount can vary substantially depending on your schema and database plan. You can estimate your required downtime by testing the upgrade and performing the upgrade process on a new database on a non-production application.

This method supports upgrades between all supported Heroku Postgres plans and versions. pg:copy only copies your default credential and the data it has access to. Any additional credentials and data that only they can access don’t get copied. You can also test the version upgrade using this method beforehand.

1. Provision a New Database

Provision a new Heroku Postgres database with your desired plan. In the example, the standard-0 plan is used, but you can provision the plan best suited for your needs:

$ heroku addons:create heroku-postgresql:standard-0 --app example-app
Creating heroku-postgresql:standard-0 on ⬢ example-app... ~$0.069/hour (max $50/month)
The database should be available in 3-5 minutes.

Use `heroku pg:wait` to track status.
postgresql-concave-52656 is being created in the background. The app will restart when complete...

If you want to upgrade your database to a Postgres version other than the most recent supported version, specify the version to use with the --version flag (for example, --version 16).

Standard, Premium, and Private-tier databases take a few minutes to provision. You can use the pg:wait command to notify you when provisioning is complete:

$ heroku pg:wait -a example-app
Waiting for database postgresql-concave-52656... ⢿ preparing

2. Enter Maintenance Mode to Prevent Database Writes

It’s important that no new data is written to your current primary database during the upgrade process, because it doesn’t transfer to the new database. To accomplish this, place your app into maintenance mode. If you have scheduler jobs running as well, or other external systems connecting to the database, disable them.

Maintenance mode doesn’t automatically scale down dynos. Scale down web and any non-web dynos (for example, heroku ps:scale worker=0) to ensure that no connections are writing data to the database.

 

Your application is unavailable starting at this point in the upgrade process.

$ heroku maintenance:on -a example-app
Enabling maintenance mode for example-app... done

3. Transfer Data to the New Database

To copy data from your current database to the newly provisioned database, use the pg:copy command to specify the source and target of the data transfer. Set your current database as the source and the new database you provisioned in Step 1 as the target. In this example, the DATABASE_URL is the source of the data in the transfer and HEROKU_POSTGRESQL_PINK is the target database.

$ heroku pg:copy DATABASE_URL HEROKU_POSTGRESQL_PINK --app example-app

!    WARNING: Destructive Action
!    Transfering data from DATABASE_URL to HEROKU_POSTGRESQL_PINK
!    This command will affect the app: example-app
!    To proceed, type "example-app" or re-run this command with --confirm example-app

example-app

You can also use the add-on name of your new database, for example, postgresql-concave-52656:

$ heroku pg:copy DATABASE_URL postgresql-concave-52656 --app example-app

4. Promote or Attach the New Database

If DATABASE_URL was the config var for your previous primary database, use pg:promote to promote the newly upgraded database as the new DATABASE_URL. pg:promote creates an alternate attachment for the old primary database, assigned with a new HEROKU_POSTGRESQL_<color>_URL config var. The promotion process triggers a release and restarts the app.

$ heroku pg:promote HEROKU_POSTGRESQL_PINK --app example-app
Promoting HEROKU_POSTGRESQL_PINK_URL to DATABASE_URL... done

Now the database you created in step 1 is the primary database (DATABASE_URL) for the app, although the app isn’t receiving new requests yet.

If the database you’re upgrading has a different config var other than the default DATABASE_URL, use heroku addons:attach to promote your newly upgraded database with the required alias or attachment name. If you attached your original primary database to multiple apps, you must attach your new upgraded database to those apps with addons:attach.

After the promotion, followers of your original primary database don’t automatically start to follow your new primary.

Create followers for the new primary database as needed:

$ heroku addons:create heroku-postgresql:standard-0 -a example-app -- --follow DATABASE_URL

Be sure to deprovision your old followers after you no longer need them.

5. Exit Maintenance Mode

To resume normal application operation, scale any non-web dynos back to their original levels (for example, heroku ps:scale worker=1).

Finally, turn off maintenance mode:

$ heroku maintenance:off --app example-app

Your application is now receiving requests to your new database instance. You can confirm this by running heroku pg:info. The database denoted by DATABASE_URL is considered the primary database.

If your Heroku Postgres database isn’t connected to a Heroku app, you must retrieve the connection string of the upgraded database and update your application and any external systems to point them to the new, upgraded database.

Deprovisioning the Old Primary Database

The Follower Failover and Data Copy upgrade methods involve creating a new database add-on, and your old database add-on isn’t automatically deprovisioned.

After you upgrade your database with the Follower Failover or Data Copy upgrade methods, be sure to deprovision your old primary database:

$ heroku addons:destroy HEROKU_POSTGRESQL_LAVENDER --app example-app

Dataclips that were associated with the old primary database must be reassigned to the new database. Follow the instructions on Dataclip recovery to resolve any recoverable Dataclips.

Keep reading

  • Postgres Basics

Feedback

Log in to submit feedback.

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure
  • .NET

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • © 2025 Salesforce, Inc. All rights reserved. Various trademarks held by their respective owners. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States
  • heroku.com
  • Legal
  • Terms of Service
  • Privacy Information
  • Responsible Disclosure
  • Trust
  • Contact
  • Cookie Preferences
  • Your Privacy Choices