Your database has reached EOL - must you always upgrade?

Open source databases can be maintained for longer, but delayed decisions can store up trouble

In February, MySQL version 5.6 reached end of life, meaning it no longer receives security or functional and nor will bugs be fixed by the core developers. The same fate awaits another popular open source database, MongoDB v3.6, in April.

So what should organisations do when their open source database reaches end of life (EOL)? In view of all the community-based help available on Stack Overflow and the like, is it really essential to upgrade to the latest and greatest? After all replacing a key part of the stack always carries the risk of disruption and could prove a major sink of money and time. We asked three providers for their views.

There is absolutely no need to upgrade for the sake of upgrading

Graham Thomson is CTO and co-founder at 3T Software Labs, which builds multi-platform tools for MongoDB.

"There is absolutely no need to upgrade for the sake of upgrading," he said, explaining that in the worst case scenario the software will just stop receiving updates and will remain as it was on its last day of support, which, depending on the applications supported, may be nothing to worry about.

"Running outdated versions of databases may not be a problem. In fact, we've seen mission-critical production databases running very old database engines, but because their scope and use has been distilled through multiple iterations, their setup runs better than anything an upgrade proponent could suggest," said Thomson, adding that managers should try to ignore the inevitable pressure from developers who simply want to try the new and shiny.

"It takes a very pragmatic technical middle management to resist this temptation. What is important, however, is that they have tools that allow for working with their current editions and that they won't lose compatibility if they upgrade a secondary service or tool."

Individual organisations must weigh up the pros and cons of upgrading, including the effort and expenditure required, because it could amount to a serious amount of work, he added.

"A five-person startup may jump onto the latest and greatest without second thought, but for a 10,000-people enterprise it's a different matter."

Matt Yonkovit, head of open source strategy at database specialist Percona, says the decision whether or not to upgrade will also depend on the database itself. In the case of MongoDB, for example, 3.6 is the last version to be licensed as fully open source AGPL, which might be a deciding factor. Other databases have their own quirks.

"Some open source databases already lag behind on security updates and performance challenges. MySQL is a good example of this, as it can be difficult to see changes being made upstream and how these can then be backported to older versions," said Yonkovit.

"Older editions should still be compatible, but the work has to be done by the community for it to happen."

Out of sight out of mind

Organisations should always have a strategy for EOL, but databases are buried deep in the stack which makes them easy to ignore, including in terms of maintenance, said Maurizio Turatti, partner at digital transformation consultancy SoftInstigate.

"In our experience the attitude of most customers towards dealing with database updates is ‘they just work, so don't touch them'. As they are usually perceived as a commodity, unless handling data is a core business activity, the most frequent reason for not planning upgrades is a mixture of plain laziness together with a reasonable amount of fear about touching a fundamental layer of any software architecture."

These kinds of projects can be a lot of work with no immediate ROI, so they get pushed to the back of the queue

Percona's Yonkovit agreed. Mañana thinking is commonplace.

"There is the old saying, ‘if it's not broken, don't fix it'", he said. "These kinds of projects can be a lot of work with no immediate ROI, so they get pushed to the back of the queue."

To be fair, upgrade delays may happen for many legitimate reasons too. The Covid crisis may have pushed database upgrades onto the back burner, while in other organisations their database is part of a critical application that they can't take down.

Planning ahead

A database is like any other piece of software or infrastructure. It may function uncomplainingly, continuing to provide a service for a long, long time, but eventually it will become incompatible with the surrounding stack and become a drain on resources. It's this, rather than security issues, that is often the main issue that prompts management to seek an upgrade, said 3T's Thomson.

"If you rely only on the built-in product security and not on a layered defence plan, you are missing the point of security. Besides, if one assumes there are holes in the product that you use, that won't go away after the upgrade. Upgrading doesn't guarantee security."

Upgrades are very important decisions and should be carefully weighed as a result

However, an upgrade may also require other elements in the stack to be updated, which could open a real can of worms: "Before you know it, the chain of updates leads you to a totally unknown place, with a lot of previously unknown problems, which you may potentially experience issues with for years.

"Upgrades are very important decisions and should be carefully weighed as a result."

For SoftInstigate's Turatti, the important thing is not to be taken by surprise: "Our strategy is simply to keep the database engine up to date with the latest major stable release as much as possible, exactly to avoid the case of being forced to upgrade under an emergency. For example, none of our customers are still running any MongoDB 3.x release since last year, we upgraded most of them to 4.0 and 4.2 already. The idea is to schedule yearly upgrades regardless of other ongoing activities, so that everybody can plan accordingly."

Yonkovit advised: "Don't let your systems get too far behind the update curve. There can be more problems if you have to go from a very old version to the latest one. Like exercise, little and often is better. Know the dates for end of life software across your stack, and when you might need to consider making changes."

On a positive note, Turatti concluded that using open source databases takes some of the-all-or nothing character out of the decision.

"Database EOL notices can be always painful, but usually much less than when dealing with closed source products, as there's always the possibility for a smoother transition thanks to community resources."