MUMPS (aka M) runs Epic. It runs VistA. It runs large chunks of the global healthcare stack you interact with without knowing. It turns 60 this year, it has a syntax that would embarrass Perl on its worst day, and it is — by far — the fastest hierarchical key-value store I’ve ever touched in anger. Every time I mention MUMPS in a meeting, someone laughs — and then they find out we were serious.

What MUMPS actually is

MUMPS is two things at once:

  1. A programming language, designed in 1966, with implicit variable declarations, one-character commands, and a control-flow model that predates structured programming. Reading MUMPS code cold is an experience.
  2. A hierarchical database, addressable as ^globalName(subscript1, subscript2, …), persistent by default. Writing to a global is a disk write. Reading it is a disk read. The language and the database are welded together; there is no “ORM,” because the program is writing to the data structure directly.

The result is a system where a well-written MUMPS program can do thousands of operations per second on a single core from the ’90s and not break a sweat. The storage engine is hilariously efficient because it was written by people who considered 64 KB of RAM a luxury and designed accordingly.

Why it still ships in 2026

The obvious question is: why is anyone still using this? A few reasons that nobody writes blog posts about:

  • It’s brutally reliable. The global storage model is transactional and crash-safe. MUMPS installations that have been running for 30 years without a data-loss incident are not rare; they’re typical.
  • The code + data colocation is a performance weapon. Modern three-tier architectures pay a round-trip cost per database access. MUMPS pays nothing — the data structure is literally addressable from the executing line of code. For workloads that are hot on small reads and writes (think: pharmacy lookups, patient chart access, lab result writes), it still beats most things in real-world benchmarks.
  • Migration cost is terrifying. Epic’s codebase has accreted for 40 years. A full rewrite is not an 18-month project; it’s a multi-decade one. The correct strategic question is not “when do we replace it?” but “what do we build alongside it?”

What I learned working near it

At HAKEEM, we ran into VistA/MUMPS components because Jordan’s public health IT had adopted pieces of the VA’s open-source healthcare stack. At AFAQ, we integrated with pharmacy systems whose data layer was MUMPS-adjacent. I don’t claim to be a MUMPS expert — I wrote maybe a few thousand lines of it across those years. What I do claim is that those few thousand lines taught me more about database design than a lot of the modern RDBMS work I did afterwards.

Specifically:

  • Subscripted key design matters more than you think. Picking the right hierarchy of keys is the MUMPS equivalent of schema design. Get it wrong and your reads scan too much. Get it right and you get O(1) access to exactly the bytes you want.
  • The cost model is visible in the code. SET ^patient(id, "name")=value is a disk operation. You cannot hide that behind an ORM. This makes you think about data access at a level modern languages encourage you to ignore.
  • Global locks are a feature, not a bug. The MUMPS locking model is primitive, which means you can reason about it. Modern distributed locking is sophisticated, which means you can’t.

The 2026 version of this

If I were starting a new greenfield transactional healthcare system in 2026, would I pick MUMPS? No. I’d use Postgres with careful schema design and explicit transactional boundaries, and I’d live a happier life.

But I would also refuse to mock the codebases that are still running MUMPS in production. They are load-bearing parts of hospital systems that keep people alive. The engineers maintaining them are disproportionately skilled in ways modern web engineers don’t recognise: they understand storage costs at a byte level, they can reason about decades-old invariants, and they have a relationship with their production data that FAANG engineers haven’t had in 20 years.

The pull-quote

If someone on your team laughs at a MUMPS codebase, they’re telling you something about themselves, not about the codebase. Ask them whether their last greenfield rewrite has been in production for 30 years. If the answer is “no,” then the laughter is premature.

The oldest code still running production is almost always the code that’s least worth laughing at.