Last updated May 19, 2026

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. Choosing the right plan depends on your app’s specific usage characteristics, including requirements for availability and uptime.

Plan Tiers

Heroku Postgres’s many plans are divided into six high-level tiers. The primary difference between each tier is the amount of tolerated monthly downtime for databases in the tier. The six tiers are:

• Essential Tier — For apps that can tolerate up to 4 hours of downtime per month
• Advanced Tier (Limited GA)
• Standard Tier — For apps that can tolerate up to 1 hour of downtime per month
• Premium Tier — For apps that can tolerate up to 15 minutes of downtime per month
• Private Tier — For verified Heroku Teams and in Heroku Enterprise customers
• Shield Tier — For verified Heroku Teams and in Heroku Enterprise customers who need compliance-capable databases

Here’s a breakdown of the differences between the tiers:

Shared Features

All Heroku Postgres plan tiers share the following features:

• Fully managed database service with automatic health checks
• Write-ahead log (WAL) off-premise storage every 60 seconds, ensuring minimal data loss if there’s a catastrophic failure
• Daily logical database backups with PG Backups (optional but free)
• Dataclips for easy and secure sharing of data and queries
• SSL-protected psql/libpq access
• Running Postgres 15, 16, 17
• Postgres extensions
• A full-featured web UI from the Heroku Dashboard
• Automatic encryption-at-rest of all data written to disk

Essential Tier

The Essential tier includes the essential-0, essential-1, and essential-2 plans. This tier has the following limitations:

• No fork and follow support: Fork and follow, used to create replica databases and leader-follower setups, aren’t supported.
• No Expensive Queries support
• Expected uptime of 99.5% each month
• Unannounced maintenance and automatic Postgres version upgrades
• No Postgres logs
• No additional credentials

The plans for the Essentials tier are:

Advanced Tier

The Advanced tier offers default plan levels that you can customize.

All Advanced databases:

• Include 100 GB of storage per cluster with a maximum storage of 100 TB. Contact Heroku Support if you need more than the maximum storage. See Storage Quotas and Thresholds for more information.
• Connection limits on Heroku Postgres Advanced databases are per instance on follower pools. See Connection Limits for more information.
• Include unlimited IOPS.
• Include a table limit of up to 4,000 tables.
• Support Private and Shield Spaces. Default plan levels are created on the Common Runtime.
• Support high availability. HA is enabled by default on the leader instance pool.
• Support scaling follower pools. Default plan levels are created without follower pools.

Plan Levels

The Advanced database plan levels are:

Standard Tier

The Standard tier is designed for applications that can tolerate up to 1 hour of downtime in any given month. All Standard-tier databases include:

• Increasing amounts of in-memory cache
• Fork and follow support
• Rollback up to 4 days
• Database metrics published to application log stream for further analysis
• Priority service restoration on disruptions
• Credential Management

The plans for the Standard tier are:

Premium Tier

The Premium tier is designed for applications that can tolerate up to 15 minutes of downtime in any given month. All Premium tier databases include:

• Increasing amounts of in-memory cache
• Fork and follow support
• Rollback up to 7 days
• Database metrics published to application log stream for further analysis
• Priority service restoration on disruptions
• Credential Management
• High availability

The plans for the Premium tier are:

Private and Shield Tiers

Heroku offers Heroku Postgres in Private Spaces for verified Heroku Teams and Heroku Enterprise customers. Additionally, Postgres Shield plans are available for customers who need compliance-capable databases. For details on our Private and Shield plans, see the Heroku Postgres and Private Spaces article.

Cache Size

For databases that aren’t in the Essential tier, RAM size indicates the total amount of System Memory on the underlying instance’s hardware, most of which is given to Postgres and used for caching. Although a small amount of RAM is used for managing connections and other tasks, Postgres takes advantage of almost all of this RAM for its cache. Learn more about how caching works in this article.

Postgres constantly manages the cache of your data: rows you’ve written, indexes you’ve made, and metadata Postgres keeps. When the data required for a query is contained entirely in the cache, performance is fast. Queries made from cached data are often 100-1000x faster than queries made from the full dataset.

Conversely, having to fall back to disk is at least an order of magnitude slower. Additionally, columns with large data types (for example, large text columns) are stored out-of-line via TOAST, and accessing large amounts of TOASTed data can be slow.

General Guidelines

Access patterns vary greatly from application to application. Many applications access only a small, recently modified portion of their overall data. Postgres can always keep that portion in its cache as time goes on, and consequently these applications can perform well on smaller plans.

Applications that frequently access all of their data don’t have this luxury. These apps can observe dramatic increases in performance by ensuring that their entire dataset fits in memory. To determine the total size of your dataset, use the heroku pg:info command and look for the Data Size row:

$ heroku pg:info
=== HEROKU_POSTGRESQL_CHARCOAL_URL (DATABASE_URL)
Plan:        Standard 0
Status:      Available
Data Size:   9.4 MB
...

Although a crude measure, choosing a plan that has at least as much in-memory cache available as the size of your total dataset ensures high cache ratios. However, you eventually reach the point where you have more data than the largest plan, and you have to shard. Plan ahead for sharding: it takes a long time to execute a sharding strategy.

Determining Required Cache Size

There’s no substitute for observing the database demands of your application with live traffic to determine the appropriate cache size. Ideally, your cache hit ratio is in the 99%+ range. Uncommon queries require less than 100 ms and common ones less than 10 ms.

To measure the cache hit ratio for tables:

SELECT
    'cache hit rate' AS name,
     sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS ratio
FROM pg_statio_user_tables;

Or the cache hit ratio for indexes:

SELECT
    'index hit rate' AS name,
    (sum(idx_blks_hit)) / sum(idx_blks_hit + idx_blks_read) AS ratio
FROM pg_statio_user_indexes

Both queries indicate a ratio near 0.99:

heap_read | heap_hit |         ratio
-----------+----------+------------------------
       171 |   503551 | 0.99966041175571094090

When the cache hit ratio begins to decrease, upgrading your database generally brings the ratio back up to 99%.

Changing Heroku Postgres Plans

You can change the plan for a database after it has been created. To change plans on classic Postgres databases, see Changing the Plan or Infrastructure of a Heroku Postgres Database.

To change the configuration of an Advanced database after it’s been created, see Managing Instance Pools on Heroku Postgres Advanced.