Heroku Data for Redis Hobby Tier Version Deprecation

Last updated November 28, 2022

This article is a work in progress, or documents a feature that is not yet released to all users. This article is unlisted. Only those with the link can access it.

As of November 28, 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.

On March 10, 2021, we marked Heroku Data for Redis versions 4 and 5 as deprecated for hobby tier plans. This means current users will need to upgrade their add-ons to version 6. While this is expected to be a straightforward and backward-compatible upgrade for most users, it is recommended that you read this entire article to familiarize yourself with the process, as well as possible breaking changes across versions.

Users that did not proactively upgrade their add-on to version 6 were automatically upgraded after the deadline of June 30, 2021.

Timeline

Event Date
Announcement March 8, 2021
Email reminders every 30 days until deadline
Deadline June 30, 2021
Forced upgrades begin June 30, 2021

Affected Add-ons

  • Heroku Data for Redis 4 on a hobby plan (Hobby Dev)
  • Heroku Data for Redis 5 on a hobby plan (Hobby Dev)

How to Migrate

Fastest Method

You can create a new Heroku Data for Redis add-on using version 6 and destroy the old add-on.

This method doesn’t persist the data contents from the old add-on to the new one.

$ heroku addons:create heroku-redis:hobby-dev --app sushi
$ heroku addons:destroy <old-redis-haiku-name> --app sushi

# optionally attach as REDIS
$ heroku addons:attach <new-redis-haiku-name> --as REDIS --app sushi

Slower Method that Preserves Data

If you prefer to preserve the data across upgrades, you will need to create a new Redis add-on fork and promote it during an application maintenance. We have documented the version upgrade process.

Updates to Your Add-on Configuration

Heroku Data for Redis hobby add-ons using version 6 will see two connection strings published to their app’s config vars:

REDIS_URL:      redis://:password@hostname:port
REDIS_TLS_URL:  rediss://:password@hostname:tls-port

Continued use of the plaintext REDIS_URL function as expected, even after upgrading from version 4 or 5 to version 6. However, we recommend using the encrypted REDIS_TLS_URL for all client connections.

In the future, the plaintext redis:// connection string will be replaced with the encrypted rediss:// connection string. It is recommended that users transition their application’s configuration to support and use the TLS connection string to make secure client connections to their Heroku Data for Redis add-on.

At this time, when establishing an encrypted client connection, you must skip certificate verification. More details about language-specific client connections can be found in our Dev Center article and Help Center article.

Possible Breaking Changes Upgrading to Redis 6

Migrating from 4.0 to 5.0

Where possible, we changed noninclusive terms to align with our company value of Equality. We retained noninclusive terms to document a third-party system, but we encourage the developer community to embrace more inclusive language. We will update the term when it’s no longer required for technical accuracy.

Redis 4.0 is mostly a strict subset of 5.0, you should not have any problem upgrading your application from 4.0 to 5.0. However this is a list of small non-backward compatible changes introduced in the 5.0 release:

  • redis-cli now implements the cluster management tool. We still ship the old redis-trib, but new fixes will be implemented only in redis-cli. See redis-cli --cluster help for more info.
  • The RDB format changed. Redis 5.0 is still able to read 4.0 (and all the past versions) files, but not the other way around.
  • Certain log formats and sentences are different in Redis 5.0.
  • Now by default maxmemory is ignored by slaves, and used only once a slave is promoted to master. It means that in setups where you want slaves to enforce maxmemory in an independent way from the master (that will anyway stream the key eviction DEL commands), you should active this feature manually and make sure you understand that it breaks consistency if writes are not always idempotent. TLDR: the new behavior is much better for 99.999% of use cases, revert it if you really know what you are doing.
  • Scripts are only replicated by their effects and not by sending EVAL/EVALSHA to slaves or the AOF log itself. This is much better in the general case and in the future we want to totally remove the other possiblity of propagating scripts the old way (as EVAL). However you can still turn this back to the default via the non-documented (if not here) Redis configuration directive “lua-replicate-commands yes” or “DEBUG lua-always-replicate-commands 0”. However note that Redis 6 may completely remove such feature.
  • Because of the above change related to scripts replication, certain Redis commands that in Redis 4 had their result ordered lexicographically before being passed to Lua via the return value of redis.call(), now have a behavior more similar to calling the commands directly from a normal client. For instance the ordering of elements returned by SMEMBERS or SDIFF is now undetermined in Lua, exactly as it is by default when calling the commands from a non-scripting context.

Source: Redis 5 Release Notes

Migrating from 5.0 to 6.0

Redis 6.0 is mostly a strict superset of 5.0, you should not have any problem upgrading your application from 5.0 to 6.0. However this is a list of small non-backward compatible changes introduced in the 6.0 release:

  • The “SPOP count” command no longer returns null when the set key does not exist. Now it returns the empty set as it should and as happens when it is called with a 0 argument. This is technically a fix, however it changes the old behavior.

Source: Redis 6 Release Notes

Feedback

Log in to submit feedback.