Last updated May 18, 2026

All Advanced (Limited GA) databases and primary databases on Premium, Private and Shield tier plans come with the High Availability (HA) feature. HA is different in Advanced databases and classic Postgres databases.

HA in Advanced Databases

In Advanced databases, high availability is classified as having two or more compute instances within a pool. A leader pool can have a standby instance to replace the leader instance in case of an outage when you enable HA. Disabling HA in the leader pool disables the standby instance. Follower pools are considered HA enabled when there are two or more instances. See Managing Instance Pools on Heroku Postgres Advanced for more information.

Enable High Availability on a Leader Pool

By default, an Advanced database provisions a standby instance for high availability when you provision a database unless you choose to disable it. Enabling HA in a leader pool adds a standby instance in the leader instance pool, and increases the instance count from the 1 leader instance to the 2 leader instance and standby instance.

You can enable HA with the interactive data:pg:update command and selecting Enable high availability when prompted:

$ heroku data:pg:update -a example-app

? Select the Heroku Postgres Advanced database to update: (Use arrow keys)
  postgresql-horizonal-12345 (DATABASE)
> postgresql-rectangular-1234 (HEROKU_POSTGRESQL_COBALT)

? Select the pool update, or add a follower pool: (Use arrow keys)
> Leader: 4G-Performance 2 vCPU 4 GB MEM 1 instance starting at $65/month each
  Follower analytics: 16G-Performance 4 vCPU 16 GB MEM 1 instance starting at $260/month
  ──────────────
  Add a follower pool
  Exit

Selected leader pool postgresql-rectangular-1234 (4G-Performance 2 vCPU 4 GB MEM) with 1 instance

? What do you want to do?: (Use arrow keys)
  Change leader level
> Update high availability
  ──────────────
  Go back

The leader pool only has one instance and doesn’t have high availability enabled. If you enable high availability, you add a standby instance to the leader pool for redundancy.
? Do you want to enable high availability? (Use arrow keys)
  Enable high availability
  Don't enable high availability

If you provision a database through flags instead of the interactive prompts, you can enable HA with the --high-availability flag.

$ heroku data:pg:create --level 4G-Performance --high-availability -a example-app

Disable High Availability on a Leader Pool

You can disable HA when provisioning a database by selecting Remove high availability during the interactive provisioning prompts. You can also disable HA with the interactive data:pg:update command and selecting Disable high availability when prompted:

$ heroku data:pg:update -a example-app

? Select the Heroku Postgres Advanced database to update: (Use arrow keys)
  postgresql-horizonal-12345 (DATABASE)
> postgresql-rectangular-1234 (HEROKU_POSTGRESQL_COBALT)

? Select the pool update, or add a follower pool: (Use arrow keys)
> Leader: 4G-Performance 2 vCPU 4 GB MEM 2 instances starting at $65/month each
  Follower analytics: 16G-Performance 4 vCPU 16 GB MEM 1 instance starting at $260/month
  ──────────────
  Add a follower pool
  Exit

Selected leader pool postgresql-rectangular-1234 (4G-Performance 2 vCPU 4 GB MEM) with 2 instances

? What do you want to do?: (Use arrow keys)
  Change leader level
> Update high availability
  ──────────────
  Go back

The leader pool has high availability enabled and includes a standby instance for redundancy. If you disable high availability, you remove the standby and you won't have redundancy on your database.
? Do you want to keep the high-availability standby instance? (Use arrow keys)
> Keep high availability
> Disable high availability

To disable high availability when provisioning a database through flags, pass the --no-high-availability flag:

$ heroku data:pg:create --level 4G-Performance --follower=2 --no-high-availability --network private -a example-app

Enable and Disable High Availability on a Follower Pool

Follower instance pools are considered HA enabled when there are two or more instances. See Managing Instance Pools on Heroku Postgres Advanced on how to add and remove instances in a follower pool.

HA in Classic Databases

The database cluster and management system in classic databases is designed to increase database availability in the face of hardware or software failure that would otherwise lead to longer downtime. When a primary database with this feature fails, it’s automatically replaced with another replica database called a standby.

The database instance that exhibited failure is consequently destroyed and the standby is reconstructed.

When this happens, it’s possible for a small, but bounded, amount of recently committed data to be lost.

The connection string of your database can change when a failover event happens. Heroku automatically updates the config vars associated with your database (for example, DATABASE_URL) and keeps them up-to-date. If you’re connecting to this database from outside of Heroku, make sure you set and update your credentials and other connection string details correctly.

Failover Conditions

In order to prevent problems commonly seen with hair-trigger failover systems, we run a suite of checks to ensure that failover is the appropriate response. These checks are run every few seconds and consist of establishing connections to the underlying host using the SSH protocol. However, when only the PostgreSQL process becomes unavailable for any reason, a failover is unnecessary and the process is simply booted back into availability instead, ensuring an even shorter downtime period whenever possible.

After our systems initially detect a problem, we confirm that the database is truly unavailable by running several checks for two minutes across multiple network locations. This prevents transient problems from triggering a failover.

Like followers, standbys are kept up to date asynchronously. This means that it’s possible for data to be committed on the primary database but not yet on the standby. In order to minimize data loss we take two important steps:

1. We don’t attempt the failover if the standby is more than 10 segments behind. This means the maximum possible loss is 160 MB or 10 minutes, whichever is less.
2. If any of the 10 segments were successfully archived through continuous protection, but not applied during the two minute confirmation period, we make sure they’re applied before bringing the standby out of read-only mode.

Typically there’s little loss to committed data.

After Failover

After a successful failover, there are a few things to keep in mind:

• The connection string for the database can change, and your app automatically restarts with the updated database’s config vars.
• The new database’s cache will be cold, so your application’s performance may be degraded for a short period of time. This will fix itself through normal usage.
• A new standby is automatically created, and HA procedures cannot be performed until it becomes available and meets our failover conditions.
• Any Postgres sequences being used, such as those for integer primary keys, may see a gap after a failover event due to the way sequences are replicated in Postgres itself.
• Standard followers of your primary database are destroyed and recreated when the failover event happens. Followers on Premium, Private and Shield plans are repointed to the correct database. If the repoint fails, the follower is destroyed and recreated.

High Availability Status

You can check the status of HA for your database by running heroku data:pg:info for Advanced databases and heroku pg:info for classic databases.