Heroku Postgres Production Tier Technical Characterization
Last updated 26 October 2015
All of the information in this document is subject to change as Heroku adapts the service to better handle customer database workloads.
The Heroku Postgres Standard, Premium, and Enterprise tier plans offer different performance characteristics based on their multitenancy, CPU, RAM and I/O architectures. This article provides a technical description of the implementation of these production plans, and some of the performance characteristics of each.
The following table outlines our production tier plans along with relevant specifications about the underlying hardware.
|Plan||vCPU||RAM||PIOPs||Multitenant||Connection Limit||Disk Size|
|standard-0 premium-0||2||1 GB||200||yes||120||64 GB|
|standard-2 premium-2||2||3.5 GB||200||yes||400||256 GB|
|standard-4 premium-4||2||15 GB||1000||no||500||512 GB|
|standard-5 premium-5||4||30 GB||2000||no||500||1 TB|
|standard-6 premium-6||8||60 GB||3000||no||500||1 TB|
|standard-7 premium-7 enterprise-7||16||120GB||4000||no||500||1 TB|
Premium and Enterprise plans are encrypted at rest by using AES-256, block-level storage encryption.
To view technical characterizations for legacy Heroku Postgres plans, visit the Legacy Plans article.
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 10MB) 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.
For single-tenant plans, a customer’s database and related management software are the sole residents of resources on the instance, offering more predictable and less variable performance. However, virtualized infrastructure is still subject to some resource contention and minor performance variations are expected.
Architecture, vCPU, RAM and I/O
All Heroku Postgres plans run on 64-bit architectures, ensuring best performance for internal Postgres operations, and interoperability with other features like Forks and Followers across all production tier plans.
vCPU are the number of virtual processors on the underlying instance. A larger number of vCPUs provide higher performance on the virtual server or instance.
RAM is the approximate amount of memory used for data caching. An in-depth discussion on Postgres caching can be found in Understanding Heroku Postgres Data Caching.
All instances are backed by EBS-optimized instances where EBS disks with provisioned IOPs are attached. PIOPs are a measure of how many I/O operations the underlying disks can perform per second. The amount of IOPs provisioned for each plan determines its I/O throughput. On write-heavy applications, I/O can be a significant bottleneck, but on read-heavy ones, your hot dataset should fit in RAM and can therefore have very high performance with lower IOPs values.