Heroku Redis Hobby Tier Version Deprecation
Last updated March 25, 2021
Table of Contents
Beginning March 10, 2021, we are marking Heroku 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 backwards-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 do not proactively upgrade their add-on to version 6 will be 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 Redis 4 on a hobby plan (Hobby Dev)
- Heroku Redis 5 on a hobby plan (Hobby Dev)
How to migrate
Fastest method
You can create a new Heroku Redis add-on using version 6 and destroy the old add-on.
This method will not 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
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 in the Heroku Redis Dev Center article.
Updates to your add-on configuration
Heroku 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
will 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 Redis add-on.
At this time, when establishing an encrypted client connection, you will need to 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
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