Listen to this article

As outlined in a previous blog post, Heroku Data services undergo routine maintenances for security and patching. In this post, we describe the process used to minimize downtime for Heroku Postgres and Heroku Redis premium ‘High Availability’ plans and how we optimized the process to perform up to 75% faster.

Data Services Architecture

High availability plans for Postgres and Redis are designed to have two database instances running at the same time. One is a writeable primary database server and the other is a read-only hidden standby. Since the standby is hidden, customers cannot access it during normal operations.

Before starting a planned maintenance, we...

There are many reasons to choose Heroku Data services, but keeping the services you use secure and up-to-date rank near the top. This foundation of trust is the most important commitment we make to our customers, and frequent and timely maintenances are one way we deliver on this promise.

We do everything we can to minimize downtime, which is typically between 10 – 60 seconds per maintenance. There are ways for you to minimize disruption too (see the tips and tricks below). The rest of the post explains how we think about Heroku Data maintenances, how we perform them, and when we perform them.

An Ounce of Prevention...

Hackers exploit known but unpatched vulnerabilities or out-of-date...

Setting up a database is a relatively straightforward process (Heroku has an add-on for that), but getting it to run well in production is sometimes another matter. As your application grows and your data grows along with it, you will likely find a number of performance bottlenecks specifically related to your database, and this post aims to help you diagnose and address those issues when they arise.

As with all components of your infrastructure it’s important to have early visibility into the performance characteristics of your database. Watching this data as your application grows will give you a much better chance of spotting performance issues and regressions as they’re introduced.

I...

Over the past few weeks, Heroku proactively updated our entire Redis fleet with a version of Redis not vulnerable to CVE-2018-11218. This was an embargoed vulnerability, so we did this work without notifying our customers about the underlying cause. As always, our goal was to update all Heroku Redis instances well before the embargo expired.

As a Data Infrastructure Engineer at Heroku, I wanted to share how we manage large fleet operations such as this one. The most important aspect of our job is keeping customers safe from security vulnerabilities, while also minimizing disruption and downtime. Those two objectives are often at odds with each other, so we work hard to reduce the impact...

On May 10, 2018, we received notice about two critical vulnerabilities in Redis, both embargoed until this morning.

Upon this notice, our Data Infrastructure team proceeded to patch all internal and customer databases in response to these vulnerabilities. As of today, all customer databases have been patched successfully.

At Heroku, customer trust is our most important value - and we are grateful to have your trust in keeping a globally-distributed data fleet safe from harm. If you’re interested in more behind the scenes details, check out our engineering blog post on how our Data Infrastructure team undertook the effort to patch our entire Redis fleet.