Choosing the Right Heroku Postgres Plan
Last updated September 26, 2024
Table of Contents
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 five high-level tiers. The primary difference between each tier is the amount of tolerated monthly downtime for databases in the tier. The five tiers are:
- Essential Tier — For apps that can tolerate up to 4 hours of downtime per month
- 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 Heroku Enterprise customers
- Shield Tier — For Heroku Enterprise customers who need compliance-capable databases
Here’s a breakdown of the differences between the tiers:
Heroku Postgres tier | Downtime Tolerance | Fork | Follow | Rollback | HA | Disk Encryption |
---|---|---|---|---|---|---|
Essential | < 4-hr downtime per mo. | No | No | No | No | Yes |
Standard | < 1-hr downtime per mo. | Yes | Yes | 4 days | No | Yes |
Premium | < 15-min downtime per mo. | Yes | Yes | 1 week | Yes | Yes |
Private | < 15-min downtime per mo. | Yes | Yes | 1 week | Yes | Yes |
Shield | < 15-min downtime per mo. | Yes | Yes | 1 week | Yes | Yes |
Downtime tolerance is based on a 30-day month.
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 unmodified PostgreSQL 13, 14, 15, 16
Essential-0, Essential-1, and Essential-2 plans support PostgreSQL versions 14, 15, and 16.
- Postgres extensions
- A full-featured web UI
- Automatic encryption-at-rest of all data written to disk
Dataclips and daily logical backups aren’t available for Shield-tier database plans.
Essential Tier
The Essential tier includes the essential-0
, essential-1
, essential-2
, mini
and basic
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
If you get the error The authentication type 10 is not supported.
or SCRAM authentication is not supported by this driver.
while connecting to your Essential database, see this Help article.
The plans for the Essentials tier are:
Heroku Postgres mini
and basic
plans have reached end-of-life (EOL). You can no longer provision mini
and basic
add-ons. We’re also migrating mini
and basic
databases to the new Essential-tier plans. See Mini and Basic Deprecation Details for more information.
Plan Name | Provisioning Name | Limits | Disk Size | Connection Limit | Status |
---|---|---|---|---|---|
Essential-0 | heroku-postgresql:essential-0 |
4,000 tables | 1 GB | 20 | Available |
Essential-1 | heroku-postgresql:essential-1 |
4,000 tables | 10 GB | 20 | Available |
Essential-2 | heroku-postgresql:essential-2 |
4,000 tables | 32 GB | 40 | Available |
Mini | heroku-postgresql:mini |
10,000 rows | 1 GB | 20 | EOL |
Basic | heroku-postgresql:basic |
10,000,000 rows | 10 GB | 20 | EOL |
Mini and Basic Deprecation Details
Heroku Postgres mini and basic plans have reached end-of-life (EOL). Our schedule for deprecating and migrating all mini and basic databases is as follows and subject to change:
- May 29, 2024:
mini
andbasic
plans reach EOL.- You can’t create
mini
andbasic
databases. You can still use your existingmini
andbasic
databases. - We start migrating
mini
plans toessential-0
andbasic
plans toessential-1
. We send an email notification when the migration starts and ends. Migrations take approximately 15 minutes. If yourmini
andbasic
databases are on PostgreSQL versions 12 or 13, the migration to anessential-*
database also upgrades the version to 14. - If there are issues during the migration, we notify you to help resolve them. You must successfully migrate within 30 days of receiving that email. If you don’t migrate within that timeframe, we send email notifications and start restricting database access and deleting
mini
andbasic
databases.
- You can’t create
You can migrate your mini
and basic
databases to the new Essential-tier plans with addons:upgrade
. If your mini
and basic
databases are on PostgreSQL versions 12 or 13, migrating your databases also upgrades the PostgreSQL version to 14.
If your review apps and CI apps use mini
or basic
databases in the app.json, you must update them to the new Essential-tier plans.
Plan Limit Enforcement
Plan limits are enforced with the following mechanism:
- When an Essential database reaches 90% of a usage limit, the owner receives a warning email.
- When the database exceeds a plan limit, the owner receives an additional notification. At this point, the database receives a 7-day grace period to comply with the limit or migrate to another plan. If your database is over 200% of the plan limit at any time, we skip the grace period and immediately revoke access.
- If the database is still exceeding any plan limits after 7 days or is over 200% of the plan limit, we revoke INSERT and UPDATE privileges and limit the number of connections to 1 on the database. You can still read, update, or delete data from the database so that you can bring your database into compliance and retain access to your data.
- If the database is still in violation of our plan limits, we revoke access to the database for an additional 7 days. The owner must create a support ticket to regain access to the database.
- When the usage is back in compliance with the plan limit, we automatically restore privileges and connections to the database. Restoring privileges can take some time.
- If you haven’t contacted via a support ticket and the usage continues to exceed the plan limit, we flag the database for deletion due to non-compliance to our policy.
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:
- No row limitations
- 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:
Plan Name | Provisioning Name | RAM Size | Disk Size | Connection Limit |
---|---|---|---|---|
Standard-0 | heroku-postgresql:standard-0 |
4 GB | 64 GB | 120 |
Standard-2 | heroku-postgresql:standard-2 |
8 GB | 256 GB | 400 |
Standard-3 | heroku-postgresql:standard-3 |
15 GB | 512 GB | 500 |
Standard-4 | heroku-postgresql:standard-4 |
30 GB | 768 GB | 500 |
Standard-5 | heroku-postgresql:standard-5 |
61 GB | 1 TB | 500 |
Standard-6 | heroku-postgresql:standard-6 |
122 GB | 1.5 TB | 500 |
Standard-7 | heroku-postgresql:standard-7 |
244 GB | 2 TB | 500 |
Standard-8 | heroku-postgresql:standard-8 |
488 GB | 3 TB | 500 |
Standard-9 | heroku-postgresql:standard-9 |
768 GB | 4 TB | 500 |
Standard-10 | heroku-postgresql:standard-10 |
1 TB | 8 TB | 500 |
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:
- No row limitations
- 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
The plans for the Premium tier are:
Plan Name | Provisioning Name | RAM Size | Disk Size | Connection Limit |
---|---|---|---|---|
Premium-0 | heroku-postgresql:premium-0 |
4 GB | 64 GB | 120 |
Premium-2 | heroku-postgresql:premium-2 |
8 GB | 256 GB | 400 |
Premium-3 | heroku-postgresql:premium-3 |
15 GB | 512 GB | 500 |
Premium-4 | heroku-postgresql:premium-4 |
30 GB | 768 GB | 500 |
Premium-5 | heroku-postgresql:premium-5 |
61 GB | 1 TB | 500 |
Premium-6 | heroku-postgresql:premium-6 |
122 GB | 1.5 TB | 500 |
Premium-L-6 | heroku-postgresql:premium-l-6 |
122 GB | 2 TB | 500 |
Premium-XL-6 | heroku-postgresql:premium-xl-6 |
122 GB | 3 TB | 500 |
Premium-7 | heroku-postgresql:premium-7 |
244 GB | 2 TB | 500 |
Premium-8 | heroku-postgresql:premium-8 |
488 GB | 3 TB | 500 |
Premium-9 | heroku-postgresql:premium-9 |
768 GB | 4 TB | 500 |
Premium-L-9 | heroku-postgresql:premium-l-9 |
768 GB | 5 TB | 500 |
Premium-XL-9 | heroku-postgresql:premium-xl-9 |
768 GB | 6 TB | 500 |
Premium-10 | heroku-postgresql:premium-10 |
1 TB | 8 TB | 500 |
Private and Shield Tiers
Heroku offers Heroku Postgres in private spaces for 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.
99% or more of queries served from well-engineered, high-performance web applications are served from cache.
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.
This blog post includes a deeper discussion of Postgres performance concerns and techniques.
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
You can install the pg extras plugin and then simply run heroku pg:cache-hit.
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. Find details of the options for changing plans here.