2026 should be a year of database updates, upgrades, and migrations. Across all of the most commonly used open source databases, end-of-life dates are forcing teams to take stock and move their workloads. The alternative is to stick with what is in place. While staying put might work in the short term, it will lead to more problems and higher costs over time. At the same time, moving too quickly has its own risks and potential challenges. How can we get things just right for you and your team?
Database dates for your diary
If you use MySQL, then there is a major date to plan ahead for. On April 30, 2026, MySQL 8.0 will reach End of Life (EOL) status. As a Long Term Support release, MySQL 8.0 is at the heart of many applications, so there should be a lot of planning completed already around moving to new systems. For those of you running PostgreSQL, version 13 is already End of Life, and version 14 will move to EOL status when version 19 of PostgreSQL is released in September 2026. Redis will see two end-of-life dates in 2026, with 7.2 going EOL in February 2026 and 7.4 in November. Outside open source, MongoDB 6.0 will reach EoL status in June 2026.
For teams running any of these databases, planning ahead around updates will involve a lot of work. For teams that follow a best-of-breed approach and use multiple databases in their stacks for different workloads, the challenge is even greater. Any migration should ideally start at least six months early to allow enough time for testing, compatibility checks, and successful cut-overs in advance of any end-of-life date. Yet the world of IT is rarely ideal; these applications might be critical to the business, leading to compressed timelines or even projects being postponed repeatedly. In a world where “if it’s not broken, don’t try to fix it” is often sage advice, a database migration might be seen as a lot of work for very little reward and high risk when things don’t go according to plan.
