Data has a longer memory than software
Consider what happens to a person born today. The data trail that comes with them—government records, bank accounts, pension contributions—is not a short-lived artifact. It has to remain accessible and intact for decades, often outliving the individuals it describes.
- Life expectancy: 82 years
- Government data: Stored for 100+ years
- Pension fund: Stored for 60+ years
- Banking data: Bank accounts might exist for decades
This is not an abstract concern. Nations store data for entire populations, and that data has to survive far beyond the typical lifecycle of a single software product or even a hardware platform. Our digital existence now carries as much weight as our physical one, which raises a hard question about the systems we trust with that burden.
Nearly always, the data outlives the application that manages it. An e-banking frontend can be redesigned or replaced on a regular cycle, but the underlying record of how much money sits in an account remains fundamentally unchanged for far longer.
That asymmetry matters because commercial database products have a poor track record of longevity. Sybase Anywhere existed from 1992 to 2025—roughly 33 years—before being discontinued. MySQL, first released in 1995, was absorbed into Oracle's portfolio when it acquired Sun in 2010. DEC/Oracle Rdb appeared in 1984, was acquired by Oracle in 1994, and lost Itanium support in 2010. Against a 100-year data retention horizon, three decades of product life is not a reassuring number.
The real risk is not that a product eventually goes away—everything does. The problem is that customers typically have no visibility into how their data is physically stored. If that data sits in a proprietary binary format on a dead architecture like Itanium, recovering it decades later can become nearly impossible. Cloud environments only amplify this risk.
The advantage of an open foundation
True open source offers a practical escape from that trap. When the code and the file formats are open, there will always be a way to keep old systems running, migrate them, or reverse-engineer what is needed. If a product fails, you can put resources toward making the existing code function again or deciphers the storage layout. A proprietary subscription service, by contrast, may simply be gone in 30 years—along with its documentation.
The math is simple: a newborn's life expectancy is roughly 82 years, and government infrastructure is expected to preserve data for more than a century. Since closed commercial products have repeatedly fallen short of those timelines, the strategy should be built around an ecosystem that does not depend on any single vendor's survival.
Thinking beyond the quarter
The practical conclusion is to stop planning around the next reporting period when it comes to data infrastructure. Business and government data is not a short-term concern. Choosing a platform means choosing how independent you will remain from vendors and their subscription models over the long run.
The question worth asking is direct: If your life depended on it, would you trust your data to a proprietary service from Amazon, Google, Alibaba, or Microsoft? Very few people would want their physical existence to hinge on the fortunes of a third-party subscription. The same logic should apply to the critical parts of our digital existence.
Open source is not just a licensing preference in this context; it is a protection mechanism for long-term data strategy. Not all data carries the same weight—your gaming high score does not demand the same guarantees as a pension fund—but the general principle holds. As data becomes more central to everyday life, the choice of where and how it is kept deserves more attention than the convenience of the nearest subscription service.
