Unlocking the Secrets of the Magic Number 35

When you run a database on RDS, regardless of the engine you use, you can set the automatic backup retention period to any number between 0 and 35 days. Running a MySQL 8.0? You can do a point in time up to 35 days in the past. Not 40 days, not 50 days, 35 days is the maximum. Oracle? 35 days. SQL Server? The continuous backups have a maximum retention of 35 days.

But why 35? What is so special about the number 35?

This is an inherent hard limit tailored for automated backups and providing point-in-time recovery, not for the purpose of archiving data for the long term. And 35 days has been the maximum for over 10 years since AWS increased the backup retention period from a maximum of 8 days in 2012. Jeff Barr wrote at that time:

After fielding a number of customer requests, we have increased the maximum retention period from 8 days to 35 days. A number of our customers have asked for this new limit in order to retain at least one month’s worth of backups for compliance purposes.

Source: https://aws.amazon.com/blogs/aws/relational-database-service-increased-snapshot-retention-period/

You might have the two-pizza team rule in AWS, but the number became quickly the limit in other services too, not RDS only.

Point-in-time recovery for DynamoDB? You can restore that table to any point in time during the last 35 days. What about Aurora? You cannot disable automated backups on Aurora, but you can choose any number as long as it is between 1 and 35. DocumentDB? It continuously backs up your data to S3 for 1 to 35 days. The number is now a de-facto standard, not only on AWS.

What about other cloud providers? Azure has 35 days:

Log backups can occur as often as every 15 minutes and can be retained for up to 35 days.

What about Google? AlloyDB recently announced:

Continuous backups have a retention period of between 1 and 35 days, depending upon the configuration that you choose when setting up this feature.

And other services on GCP and Azure match the 35 days too. But why is everyone on 35? Why not 30? Or 33 days? We can only guess:

1. Once a service uses 35, it is easier to converge on one value. For all the services of the same provider at least. Even Azure confirmed that when they increased the value for an existing service: “This change reflects our goal of providing a consistent user experience across service tiers”
2. To retain at least one month’s worth of backups for compliance purposes, you need to consider the longest month (31 days) and add a buffer for a (long) weekend that would cover an 8x5 monitoring and support scenario. Not everyone is on 24x7.
3. 35 is a tetrahedral number. I am sure it matters.

Do you have a better explanation for the magic 35? Let me know below or on Linkedin.