Standard Tier - For apps that can tolerate up to 1 hour of downtime per month.Essential Tier - For apps that can tolerate up to 4 hours of downtime per month.The primary difference between each tier is the amount of tolerated monthly downtime for databases in the tier. Plan TiersĪre divided into five high-level tiers. Choosing the right plan depends on your app’s specific usage characteristics, including requirements for availability and uptime. It can also show ‘Temporarily Unavailable’ when the standby is more than 10 segments behind, as failover will not be attempted at that time.Heroku Postgres offers a wide spectrum of plans to serve use cases that range in size from personal blogs to large-dataset, high-transaction applications. After unfollowing or after a failover event, it will show HA Status: Temporarily Unavailable while the standby is being rebuilt. In normal situations, it will show HA Status: Available. You can check the status of HA for your database by running heroku pg:info. If the repoint fails, the follower is destroyed and recreated. Followers on Premium, Private and Shield plans are repointed to the correct database. Standard followers of your primary database are destroyed and recreated when the failover event happens.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.A new standby is automatically created, and HA procedures cannot be performed until it becomes available and meets our failover conditions.This will fix itself through normal usage. The new database’s cache will be cold, so your application’s performance may be degraded for a short period of time.The URL for the database will have changed, and your app will automatically restart with the new credentials.After failoverĪfter a successful failover, there are a few things to keep in mind: These conditions are caused by application behaviour, and would be likely to persist across failovers. Out of memory conditions and exhausting concurrent connections aren’t treated as failover conditions. Typically there’s little loss to committed data. 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.This means the maximum possible loss is 160 MB or 10 minutes, whichever is less. We don’t attempt the failover if the standby is more than 10 segments behind.In order to minimize data loss we take two important steps:

This means that it’s possible for data to be committed on the primary database but not yet on the standby. Like followers, standbys are kept up to date asynchronously. This prevents transient problems from triggering a failover. 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.Īfter 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. These checks are run every few seconds and consist of establishing connections to the underlying host using the SSH protocol.

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. If you need followers for horizontal read scaling or reporting, create a new Standard Tier follower database of your primary. The standby node is hidden from your application.

Heroku postgres psequel