ZDNET’s key takeaways
- When it comes to databases, almost everyone still uses obsolete programs.
- Cost is a major reason companies aren’t upgrading
- Unsupported software comes with a host of security issues.
We all use out-of-date software. Sometimes we do it out of laziness, sometimes upgrading costs too much, and sometimes it just works, and we don’t want to replace it.
Still, when Percona, the open-source database management system (DBMS) support company, revealed in its 2026 State of Open Source Database Management Report that 97% of US-based database administrators (DBAs) were still running outdated DBMS programs, I raised my eyebrows. Really!? That’s a lot, and DBMSs are mission-critical for all companies.
Why we keep using outdated DBMSs
According to Percona, companies continue using DBMSs beyond official end-of-life primarily because upgrading is a high-risk, cross-stack migration project, not a simple software refresh. Legacy application dependencies, deprecated features, client compatibility, changed defaults, testing demands, and the need to avoid production disruption can all make postponement appear safer or cheaper in the short term. In other words, they’d rather be safe than sorry.
Of course, that presumes they can stay ahead of security breaches caused by continuing with end-of-life software. Good luck with that. That’s never a good bet these days, when AI can find security holes faster than we can fix them.
Other reasons, according to Percona, include that database upgrades are rarely simple version changes because they can expose dependencies throughout the application stack. Legacy applications may rely on deprecated or removed database features, requiring teams to identify those dependencies and revise affected code. For example, MySQL 8.0’s default caching_sha2_password authentication method can cause trouble for older clients and may require configuration changes.
Also: Switzerland takes a Swiss Army knife to Microsoft 365
Other changes require careful application-level review. A shift in default character sets, for example — from latin1 to utf8mb4 — cannot safely be assumed to be transparent to existing applications or data-handling routines. Percona also advises organizations to assess the full environment, including applications, operating systems, libraries, and configuration files, since a database migration often affects far more than the database server itself.
That complexity raises the cost and risk of moving to a supported release. Teams need to run pre-upgrade checks, validate the migration in staging, and schedule production work carefully to limit disruption — tasks that require specialist expertise, engineering time, and maintenance windows.
Major release transitions can add still more difficulty. Percona cites the upgrade from MySQL 5.7 to 8.0, which brought a substantial data-dictionary redesign and removed the query cache, as an example of why “just upgrade” is rarely an adequate plan.
Also: ‘I can’t stop’: 80% of developers find AI coding more addictive than helpful
In the broader backdrop, Percona found that database teams are constrained by rising cloud costs, performance problems, wasted engineering time, downtime concerns, scaling complexity, fragmented policies, and a shortage of skills. Those pressures reduce the organizational capacity available for lifecycle work such as database upgrades.
Money, money, money
Cost pressures were the survey’s most frequently cited obstacle to database total-cost-of-ownership reductions and upgrades.
The findings put cloud consumption costs (31%) ahead of licensing (23%) as the leading reported barrier. That matters because moving to managed database platforms can eliminate some operational work while also creating less predictable bills as storage, compute, network traffic, high availability, and data-transfer needs rise.
“Cloud economics are changing, AI is introducing new workload patterns, regulations are becoming more complex, and organizations are increasingly conscious of where their data and technology are controlled,” Percona CEO Peter Farkas said in the company’s announcement. “The organizations that will be best prepared are not necessarily those that can predict what comes next. They are the ones that preserve the freedom to adapt when it arrives.”
Performance and policy gaps
The report also depicts database operations as an engineering-efficiency and resilience problem, not merely a question of query latency:
- 42% cited inefficiency or slow throughput as a performance challenge.
- 41% cited wasted engineering time.
- 40% cited downtime.
- 37% cited difficulty scaling.
On governance, 54% said vendor lock-in makes it harder to adapt to changing regulatory requirements. More than half reported fragmented tools or policies, while 46% identified both software supply-chain traceability and a reactive security posture as concerns.
Those results link the legacy-version issue to broader management challenges. Unsupported software can complicate vulnerability management and audit requirements, while fragmented controls and database sprawl make upgrades and migration planning harder to execute consistently.
AI is not chiefly a feature gap
For AI readiness, respondents were more likely to identify foundational organizational obstacles than a shortage of database features. Fragmented data architecture and skills shortages tied as the top barriers, at 23% apiece.
That result is a useful corrective to the current rush to add vector search, embedding storage and agent-oriented capabilities to database offerings. Those capabilities may be useful, but Percona’s respondents suggest that disconnected data estates and a lack of necessary staff expertise are more immediate blockers.
Also: Open weights vs. closed: An AI civil war’s afoot
“Database leaders need to build for change, not for a single version of the future,” Farkas said. “Control and flexibility need to be requirements, not afterthoughts.” No one knows where the AI revolution will take us. For that reason, thanks to open-source flexibility, smart companies still put their DBMS resources into open-source DBMS.
See full bio
About the Author
