Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • 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 inorSign up
View categories

Categories

  • Heroku Architecture
    • Dynos (app containers)
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Command Line
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery
    • Continuous Integration
  • Language Support
    • Node.js
    • Ruby
      • Rails Support
      • Working with Bundler
    • Python
      • Background Jobs in Python
      • Working with Django
    • Java
      • Working with Maven
      • Java Database Operations
      • Working with the Play Framework
      • Working with Spring Boot
      • Java Advanced Topics
    • PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Getting Started
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
    • Heroku Data For Redis
    • Apache Kafka on Heroku
    • Other Data Stores
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
    • Compliance
  • Heroku Enterprise
    • Private Spaces
      • Infrastructure Networking
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
      • Heroku Connect Administration
      • Heroku Connect Reference
      • Heroku Connect Troubleshooting
    • Single Sign-on (SSO)
  • 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
  • Databases & Data Management
  • Heroku Postgres
  • Postgres Basics
  • Choosing the Right Heroku Postgres Plan

Choosing the Right Heroku Postgres Plan

English — 日本語に切り替える

Last updated December 28, 2022

Table of Contents

  • Plan Tiers
  • Essential Tier
  • Standard Tier
  • Premium Tier
  • Private and Shield Tiers
  • Cache Size

As of November 28th, 2022, free Heroku Dynos, free Heroku Postgres, and free Heroku Data for Redis® plans are no longer available. See our FAQ for more info. Eligible students can apply for platform credits through our new Heroku for GitHub Students program.

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 No
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 10 (deprecating), 11, 12, 13, 14
  • Postgres extensions
  • A full-featured web UI

Dataclips and daily logical backups aren’t available for Shield-tier database plans.

Essential Tier

The Essential tier includes the mini and basic plans. This tier has the following limitations:

  • Enforced row limits of 10,000 rows for mini, and 10,000,000 for basic plans
  • Maximum storage of 1 GB for mini and 10 GB for basic plans
  • Maximum of 20 connections
  • No in-memory cache: The lack of an in-memory cache limits performance, because the data can’t be accessed on low-latency storage.
  • No fork/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 database upgrades.
  • No Postgres logs.
  • No additional credentials.

Plan Limit Enforcement

When you exceed row or size limits on Essential-tier databases and try to insert, you receive a Postgres error:

permission denied for relation <table name>

The row limits of Essential-tier database plans are enforced with the following mechanism:

  1. When a mini database reaches 7,000 rows, or a basic database hits 7 million rows, the owner receives a warning email stating they’re nearing their row limits.
  2. When the database exceeds its row capacity, the owner receives an additional notification. At this point, the database receives a 7-day grace period to either reduce the number of records, or migrate to another plan.
  3. If the number of rows still exceeds the plan capacity after 7 days, INSERT privileges are revoked on the database. Data can still be read, updated, or deleted from the database. This ensures that users can bring their database into compliance and retain access to their data.
  4. When the number of rows is again in compliance with the plan limit, INSERT privileges are automatically restored to the database. Database sizes are checked asynchronously, so it can take a few minutes for privileges to be restored.

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
  • Automatic encryption-at-rest of all data written to disk
  • Credential Management

The plans for the Standard tier are:

Plan Name Provisioning Name RAM Size Disk Size Conn. 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

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
  • Automatic encryption-at-rest of all data written to disk.
  • 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-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

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 very fast. Queries made from cached data are often 100-1000x faster than those 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:        Crane
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 should 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 should 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 Postgres Plans

It’s possible to change the plan for a database after it has been created. You can find details of the options for changing plans here.

Keep reading

  • Postgres Basics

Feedback

Log in to submit feedback.

Upgrading the Version of a Heroku Postgres Database Connecting to Heroku Postgres

Information & Support

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

Language Reference

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

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences