Last updated March 05, 2025

The Heroku Postgres Performance pilot is available for customers interested in the newest Heroku Postgres product. Using new and improved infrastructure, the new tier offers flexible customization options to fit every database needs for your app. This pilot gives customers an early opportunity to experiment and provide feedback that helps guide us toward delivering world-class, user-centric database services.

Pilot Program Details

Here are the details about the pilot program:

• It’s free to participate and use pilot Performance products. We’ll conduct feedback surveys for you to share feedback so that we can improve our offering.
• The pilot is aimed at evaluating the performance and features of our new products and isn’t intended for production use.
• We’ll treat all data and feedback shared with the utmost confidentiality and use it exclusively for product enhancement.
• We’ll continually update, add, remove, or design features on pilot databases. See the Pilot Changelog for updates.
• We reserve the right to shut down the pilot databases and the pilot program at any point for any reason.

Performance Features and Components

^{An example implementation of Performance databases.}

Heroku Postgres Performance databases are made up of the following components:

• Cluster: A cluster is an instance of a Performance database. A cluster comes with one associated storage and one or more compute pools.
• Storage: Each cluster comes with a base storage amount, which is shared across compute pools. The plan level you choose for the leader instance determines the base storage amount for the entire cluster. You can exceed the base storage amount up to 128 TB.
• Compute Pool: Each cluster has at least one compute pool, which includes a required leader pool and an optional follower pool. Compute instances reside in the compute pool and share the same compute instance size, for example, 64G.
• Leader Pool: For each compute pool in a cluster, there’s one required leader pool with a leader, or writer, compute instance that performs read and write operations. There’s also an optional standby instance for high-availability (HA).
• Follower Pool: Optionally, you can create up to five follower pools within the cluster to offload read operations from the leader. You can provision one or more compute instances within the follower pool. You can name the follower pool and find it in the config var, for example main-reader.
• High Availability (HA): Having two or more compute instances within a pool enables high availability for that pool. For example in the leader pool, a leader and its standby enables HA. Having at least two instances in a follower pool enables HA in that pool. See High Availability for more information.

Use Cases

Use Performance databases if you have:

• Databases that are constrained because of mismatched storage and compute usage. For example, your app rarely exceeds 20% of load capacity in compute usage, but it’s exceeding 80% of storage capacity. The new Performance databases have the flexibility to independently scale your compute and storage needs.
• Too many database add-ons to manage. For example, you have different database add-ons for your development, staging, testing, and analytic environments. The new Performance databases let you consolidate the database add-ons to one cluster, while creating and attaching follower pools to your respective apps. This consolidation helps you track database creation and attachments.
• Apps with seasonal spike patterns. For example, your app often exceeds compute and storage capacity during certain months of the year. Instead of upgrading to a larger plan, you can scale using follower pools without restarting your application with the new Performance databases.
• Non-production apps that don’t require high availability. For example, your development app doesn’t need HA like your production app even if they’re both in a Private Space. With the new Performance databases, you can opt to have a single instance leader configuration to optimize cost.

Getting Started Guide

See our tutorial on how to create and manage Performance databases.

Performance CLI Commands

The Heroku Data Performance CLI plugin lets you to set up and manage Postgres Performance databases. Before creating a database on the new infrastructure, you must install the plugin. See Managing Heroku Postgres Performance using the CLI (Internal Pilot) for more information.

Heroku Postgres Performance Plan Levels

The Postgres Performance tier offers default plan levels that you can customize on top of. All Performance databases:

• Include a base storage amount determined by the leader instance with a maximum storage of 128 TB and no row limitations.
• Support Private and Shield Spaces. Default plan levels are created on the Common Runtime.
• Support high availability. Default plan levels don’t have HA enabled.
• Support scaling follower pools. Default plan levels are created without follower pools.
• Support PostgreSQL versions 14, 15, and 16. 16 is the default version if you don’t use the --version flag in provisioning.

The Performance database plan levels are:

See the Getting Started Guide on provisioning a Performance database.

Customizable Features

Performance databases provide flexibility over traditional Heroku Postgres databases by having customization options. These customizable features let users adjust their database to fit their needs as their app requirements change.

You can customize these options:

When customizing these features, keep in mind:

• You can only enable and disable HA on the leader pool. See High Availability for more information.
• You can’t modify the --network after creating the database. You can only specify it when you provision the database.
• For follower pools, you must use the --pool=[name] flag in the data:pg:scale command to target the follower pool you want to change.

See Managing Heroku Postgres Performance using the CLI (Internal Pilot) for the commands reference.

Instance Pools

Inside a cluster, there’s at least one leader pool and optionally up to five follower pools. The difference between a leader pool and a follower pool is that follower pools use all instances for read operations unlike an invisible standby of a leader pool. You can only adjust the compute level in the leader pool, but can adjust both the compute level and number of compute instances in a follower pool.

See the Getting Started Guide on scaling your instance pools.

Leader Pool

The leader pool has one required leader instance that performs read and write operations on your app. There’s also an optional standby instance when you enable high availability. The base storage amount in your leader instance is shared across the leader and follower pools in the cluster. For example, a 64G-Performance database has 1000 GB base storage for the entire cluster, and doesn’t accumulate if you add follower pools.

You can exceed the base storage amount up to 128 TB. At general availability, Heroku will charge for the additional storage you use over your base storage amount.

Follower Pools

You can use follower pools to scale a database’s read capacity. For example, you can use them to offload all read operations for a high-traffic application or specific use cases, such as analytics workload during a scheduled job. You can create up to five follower pools, with a maximum of 15 follower instances per cluster.

Unlike traditional database configuration with fixed storage and compute per instance like with our traditional Heroku Postgres plans, Performance databases offer flexibility in vertical scaling by increasing the compute level. You can also achieve horizontal scaling by adding more follower pools. You can scale Performance databases without restarting your app, and you can scale at any time against any compute pools.

High Availability

In Performance 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 Follower Pools for more information.

See the Getting Started Guide on enabling and disabling high availability.

Connecting to Performance Databases

All Performance database connections require TLS. You can use the following options for sslmode:

• prefer: (default) enable TLS if it’s supported, any cert being offered is acceptable if available
• require: enable TLS, any cert being offered is acceptable
• verify-ca: enable TLS, cert must be signed by a CA I trust
• verify-full: enable TLS, cert must be signed by a CA I trust and cert hostname must match the destination connection

You can configure verify-ca and verify-full with sslrootcert. For example:

"${DATABASE_URL}?sslmode=verify-full&sslrootcert=system"

The Heroku stack base images include AWS RDS certificate bundles. If you use buildpack deployments or use buildpacks for Docker-based deployments, you don’t need to add a cert. If you don’t use buildpacks or the base images, you must add the AWS RDS certificate bundle to your deployment artifact before using verify-ca and verify-full.

Limitations and Considerations

During the pilot, Performance databases don’t support the following features and capabilities. As we continue improving and adding features, we’ll update what’s new in the Pilot Changelog.

• Server-side Connection Pooling
• Global clusters

Pilot Performance databases have the following limits:

• A cluster can have up to 5 follower pools.
• A cluster can have up to 15 total instances.
• A database can have up to 4,000 tables.

Support

Submit all Heroku Postgres Performance support and runtime issues via one of the Heroku Support channels. To submit a ticket for the pilot, mention the pilot name Postgres Performance Tier in the ticket subject.

Pilot Changelog