Heroku Postgres Legacy Plans
Last updated 17 April 2018
Table of Contents
You will not be able to provision a new Heroku Postgres Legacy Plan. You are required to use the current plan lineup for new databases. Legacy plan databases that are still operating were transferred to their equivalent non-legacy plan on December 7th, 2017.
Legacy Plan Replacements (December 2017)
In December 2017, we revised Heroku Postgres Legacy plan names. We retired our kaiju-inspired (Legacy) plan names in order to provide better customer experience and easier awareness of the characteristics of each Postgres plan we offer.
Legacy Heroku Postgres database plans’ replacements are documented in the table below. All replacement plans are the same price as their legacy equivalent or cheaper.
|Legacy plan||Replacement plan||Current price per month||Replacement price per month|
|Standard Yanari||Standard 0||$50||$50|
|Standard Tengu||Standard 2||$200||$200|
|Standard Ika||Standard 4||$800||$750|
|Standard Baku||Standard 6||$2000||$2000|
|Standard Mecha||Standard 7||$3500||$3500|
|Premium Yanari||Premium 0||$200||$200|
|Premium Tengu||Premium 2||$350||$350|
Specification and technical details of Heroku Postgres Legacy plans
Second Generation Legacy Plans
The second generation legacy plans are also known as Heroku Postgres 2.0 plans.
The features of the Standard, Premium, and Enterprise tiers have similar features to the current (3rd generation) plans (with the exception of encyption-at-rest), but have about ½ the memory and less performance.
||Standard production databases.|
||Production databases with built-in hot-standbys for high-availability.|
||Production databases with premium features and uptime SLAs.|
First Generation Legacy Plans
The legacy plans consist of two tiers, starter and production, across a variety of plans.
||Free and low-cost database plans for evaluation, application development, and testing.|
||Production-grade monitoring, operations, and support.|
The starter tier database plans are not intended for production-caliber applications or applications with high-uptime requirements.
The starter tier, which includes the
plans, has the following
- Enforced row limits of 10,000 rows for
devand 10,000,000 for
- Max of 20 connections
- No in-memory cache: The lack of an in-memory cache limits the performance capabilities since the data can’t be accessed on low-latency storage.
- No fork/follow support: Fork and follow, used to create replica databases and master-slave setups, are not supported.
- Expected uptime of 99.5% each month
- No postgres logs
As the name implies, the production tier of Heroku Postgres is intended for production applications and includes the following feature additions to the starter tier:
- No row limitations
- Increasing amounts of in-memory cache
- Fork and follow support
- Max of 500 connections
- 1 TB of storage (if you need beyond 1 TB please contact us)
- Expected uptime of 99.95% each month
- Database metrics published to application log stream for further analysis
Management of production tier database plans is also much more robust including:
- Eligible for automatic daily snapshots with 1-month retention (see PGBackups for more details)
- Priority service restoration on disruptions
Non-production applications, or applications with minimal data
storage, performance or availability requirements can choose between
one of the two starter tier plans,
basic, depending on row
requirements. However, production applications, or apps that require
the features of a production tier database plan, have a variety of
plans to choose from. These plans vary primarily by the size of their
in-memory data cache.
The cache and price for each legacy production plan is:
|Plan Name||Provisioning name||Memory||Price per month|
Legacy plan technical characterizations
First Generation Legacy Plans
The following table outlines our production tier plans along with relevant specifications about the underlying hardware.
|Heroku Postgres plan||vCPU||RAM||PIOPs||Multitenant|
Second Generation Legacy Plans
|Heroku Postgres plan||vCPU||RAM||PIOPs||Multitenant||Connection Limit||Disk Size|
|Yanari||2||400 MB||200||yes||60||64 GB|
|Tengu||2||1.7 GB||200||yes||200||256 GB|
|Ika||2||7.5 GB||500||no||400||512 GB|
|Baku||4||34.2 GB||1000||no||500||1 TB|
|Mecha||8||68.4 GB||2000||no||500||1 TB|
|Ryu||32||244 GB||4000||no||500||1 TB|
Heroku Postgres databases run on virtualized infrastructure provided by AWS EC2. There are two main variants of database deployment architectures on Heroku Postgres: multi-tenant and single-tenant.
For multi-tenant plans, several LXC containers are created within a single large instance. Each LXC container holds a single database service and provides security and resource isolation within the instance.
To understand how multi-tenant databases perform, it’s important to understand how Postgres uses memory. Postgres is designed to cache some frequently accessed data itself, such as indices and frequently accessed tables. This is called “shared buffer cache”. But Postgres also relies on the host operating system’s ability to cache recently accessed disk pages in system memory.
In a typical Postgres installation (and in single-tenant Heroku Postgres installations), about 25% of the available memory will be reserved for shared buffer cache. Postgres will also use some memory (at least 10 MB) for each open connection. The remainder of system memory will be used by the operating system for page cache.
In a multi-tenant database with 1 GB of allocated RAM, your database will be configured to allocate that same 25% for shared buffer cache (about 250 MB). But the rest of system memory, including memory for open connections as well as memory for disk page cache, will be shared between all the databases running on the server.
This has benefits and drawbacks. If your database is suddenly under increased load (because of increased web traffic, for example), the operating system might choose to cache more of your disk pages, giving you a temporary boost in performance beyond what you’d otherwise expect from a single-tenant server with the promised amount of RAM. On the other hand, spikes in activity from other databases on a multi-tenant server can lead to temporary decreases in performance for your database—especially in queries that access infrequently used data.
Heroku actively monitors multi-tenant servers to ensure that each database has adequate resources available. However, sudden large changes in overall activity on a server can cause performance problems for multi-tenant databases. If that happens, you can use a follower changeover to move your database to another randomly assigned multi-tenant host, or contact Heroku support for further assistance.