A few weeks ago, IBM told investors that a slowdown in mainframe sales was a temporary blip rather than the start of a decline. Outside financial circles, the news barely registered — but among industry insiders, it sparked real debate.
It’s easy to see why the topic gets so little attention. We’re living through a moment when the entire tech industry seems fixated on artificial intelligence: companies are pouring billions into GPU-packed data centers, hardware makers are racing to build ever more powerful accelerators, and the cloud keeps expanding its footprint. Against that backdrop, it’s natural to wonder what room is left for a technology born more than sixty years ago.
But the fashionable question — “why do mainframes still exist?” — is the wrong one. The more interesting question is this: after six decades of relentless computing evolution, why do mainframes remain the operational heart of banks, insurers, airlines, government agencies, and the world’s largest enterprises? Their survival isn’t inertia or resistance to change. It’s the result of solving one extremely specific problem better than any other platform can.
Forget how you’re used to judging a computer
To understand the mainframe’s role, you have to set aside, at least for a moment, the way we normally compare computers. Over the last twenty years we’ve learned to judge machines by processor speed, core count, installed memory, or how fast they can train an AI model — practically worshipping the GPU. That’s a reasonable lens, but it only captures part of modern computing. Some systems are built with a completely different goal: not top scores on a benchmark, but the guarantee that millions of operations execute correctly, without interruption, and without ever losing data.
That’s exactly where the mainframe proves its worth. Since the 1960s it has been engineered to process enormous transaction volumes while guaranteeing continuity, reliability, and data integrity. Countless hardware architectures, operating systems, and programming languages have come and gone, but the core problem — recording a bank transaction correctly — hasn’t changed. If a wire transfer debits the sender’s account, the money has to show up in the recipient’s account too. If anything interrupts the process, the system has to roll everything back to where it started.
That’s the principle behind ACID transactions — a term every computer science student learns and almost nobody remembers clearly in practice. It’s an acronym for the four properties that guarantee data safety and reliability when a database executes a transaction — a group of operations that must be treated as a single, indivisible unit.
The four pillars of ACID:
- Atomicity — The entire transaction succeeds, or none of it does. If you transfer $50 from Account A to Account B, the system must both debit A and credit B. If it crashes halfway through, the whole operation is rolled back and no money is lost.
- Consistency — The database moves from one valid state to another, always respecting its rules and constraints. If an account legally can’t go below zero, a transaction that tries to overdraw it gets blocked.
- Isolation — Each transaction runs as if it were the only one happening. Concurrent transactions don’t interfere with each other. If two people withdraw from the same joint account at the same moment, the database processes the requests one at a time so the balance is never miscalculated.
- Durability — Once a transaction completes, the change is permanent — it survives a power outage or a server crash. The moment you get confirmation of a transfer, that data has already been safely written to disk or to a system log.
So why not just use a modern relational database?
Fair question — plenty of relational databases, and even some NoSQL ones, satisfy ACID. So why not just run everything on a conventional server?
Picture yourself, for a moment, peeling back the layers on this like a technician in an old documentary. There are several reasons a mainframe still stands apart.
Dedicated I/O handling. Ordinary PCs and standard x86 servers rely on the central CPU for almost everything: computation, application logic, and moving data to and from disk. Mainframes, by contrast, have co-processors dedicated purely to I/O. The main CPU handles computation while hundreds of secondary chips move the data. That division of labor lets a mainframe process tens of thousands of financial transactions per second without a bottleneck — throughput that’s genuinely hard to replicate on standard servers under massive global load.
Fault tolerance. Mainframes are engineered for 99.999% uptime — the famous “five nines” — meaning only minutes of downtime per year. Every hardware component (motherboards, memory, power supplies, CPUs) is duplicated or triplicated. If a part fails mid-transaction, the system hot-swaps it without going down and without losing a single bit. You can stack up all the distributed messaging and clustering technology you like — however resilient the software layer, it still depends on the underlying server or cloud infrastructure, and matching mainframe-grade reliability usually requires extremely complex clustering.
“If it works, don’t touch it.” Core banking systems have been built up in layers over 40 to 50 years, often in COBOL, with millions of lines of code interwoven with tax rules and banking logic that’s frequently undocumented. Shutting down the mainframe to migrate to something modern looks, to most executives, like a catastrophic risk: a single bug during the transition could freeze a country’s ATMs or corrupt the balances of millions of customers.
Batch-processing speed. Banks operate in two modes: real-time transactions (swiping your card) and batch processes (calculating interest on millions of accounts overnight). Mainframes were built to chew through staggering volumes of sequential data in minutes. A nightly batch job that takes 20 minutes on a mainframe could take hours on a standard relational database not optimized for that kind of workload — potentially bleeding into the start of the next business day.
Six decades of continuity
This obsession with continuity is one of the most fascinating things about the mainframe world, and it traces back to one of computing’s landmark moments. In 1964, IBM unveiled the System/360 — a family of computers that fundamentally changed how enterprise systems were designed. Until then, every new machine often meant rewriting the software built for the previous generation. The System/360 introduced a compatible platform instead, one that could grow while preserving the existing base of applications. It was a genuinely radical idea: it let companies invest in software development without fearing they’d have to start from scratch with every hardware upgrade.
Programs written decades ago are still in daily use today — not because they’re old, but because they still do their job flawlessly. In an industry like banking, an application managing millions of accounts represents an enormous asset. Rewriting it from scratch isn’t just expensive; it means years of analysis, testing, and certification, with a real risk of introducing bugs into procedures that have worked reliably for decades. So the software gets evolved incrementally instead — adapted, extended, integrated with modern technology — rather than replaced wholesale.
COBOL, misunderstood
This is the context in which COBOL still dominates — probably the most discussed and most misunderstood language in modern computing. Created in 1959 to describe administrative and business procedures clearly, COBOL was designed so its code could be read even by people who weren’t computer specialists. Unlike languages built for scientific computing, it was built around records, files, accounting entries, and business procedures. Millions of lines of COBOL still run every single day — not out of nostalgia, but because they encode business rules refined over decades.
That doesn’t mean a modern mainframe only runs sixty-year-old software. Quite the opposite — these platforms have kept evolving continuously. A modern IBM Z system can host Java applications, services written in C and C++, full Linux distributions, virtual machines, containers, and APIs that talk to cloud-native applications. In practice, the mainframe today is often just one node — albeit usually the most stable one — in a much larger distributed architecture that also includes microservices, relational databases, messaging systems, and mobile apps. It’s the anchor point where the most sensitive operations converge, while everything around it evolves at a much faster pace.
Where AI actually fits in
So if mainframes are still this important, why does the market seem almost entirely fixated on the race to build AI-dedicated systems?
The truth is the mainframe world hasn’t ignored AI at all. In recent years IBM has built dedicated inference accelerators directly into its systems, enabling fraud detection, risk analysis, and anomaly-detection models to run without ever moving data to an external platform. That distinction matters: the value here isn’t training a new model — it’s making a decision in milliseconds, at the exact moment a transaction is being authorized. Blocking a credit card used suspiciously, or flagging an anomalous wire transfer, is a concrete example of AI working alongside the mainframe rather than replacing it.
The sales slowdown IBM flagged should be read in that light. Large enterprise platforms follow very long renewal cycles, and investment is planned on timelines that have little to do with the breakneck pace of the consumer tech market. It’s not surprising that, in a period dominated by AI infrastructure spending, part of every budget gets redirected toward new accelerated-computing buildouts. But it would be a mistake to read that as a sign the mainframe is disappearing. What we’re more likely seeing is a rebalancing of investment, where different technologies coexist because they serve genuinely different needs.
The quiet machines
Maybe the reason we talk so little about mainframes is that they’re doing exactly what they’re supposed to do: working. They don’t generate flashy images, they don’t write text, they don’t show up in social media debates, and they rarely make tech headlines. And yet, every single day, they process a significant share of the economic transactions that keep modern society running. Their presence is quiet, almost invisible — and that invisibility is precisely the measure of their success. In an industry where innovation is so often judged by its ability to surprise us, the mainframe is a reminder that there’s another way to do technology: build systems so reliable that, over time, they simply become part of the landscape — the machines quietly keeping everything else running, unnoticed until the day they’re needed most.
