MUMPS (auch: M) betreibt Epic. Es betreibt VistA. Es betreibt große Teile des globalen Healthcare-Stacks, mit dem du interagierst, ohne es zu wissen. Es wird dieses Jahr 60, hat eine Syntax, die Perl an seinem schlechtesten Tag erröten lassen würde, und ist — mit weitem Abstand — der schnellste hierarchische Key-Value-Store, den ich je im Ernstfall angefasst habe. Jedes Mal, wenn ich MUMPS in einem Meeting erwähne, lacht jemand — und dann erfährt er, dass ich es ernst gemeint habe.

Was MUMPS eigentlich ist

MUMPS ist gleichzeitig zwei Dinge:

  1. Eine Programmiersprache, entworfen 1966, mit impliziten Variablendeklarationen, Ein-Buchstaben-Commands und einem Control-Flow-Modell, das strukturiertes Programmieren vorwegnimmt. MUMPS-Code kalt zu lesen ist ein Erlebnis.
  2. Eine hierarchische Datenbank, adressierbar als ^globalName(subscript1, subscript2, …), standardmäßig persistent. In ein Global schreiben ist ein Disk-Write. Es lesen ist ein Disk-Read. Sprache und Datenbank sind verschweißt; es gibt kein “ORM”, weil das Programm direkt in die Datenstruktur schreibt.

Das Ergebnis ist ein System, bei dem ein gut geschriebenes MUMPS-Programm Tausende von Operationen pro Sekunde auf einem einzelnen Kern aus den 90ern durchführen kann, ohne ins Schwitzen zu kommen. Die Storage-Engine ist wahnwitzig effizient, weil sie von Leuten geschrieben wurde, die 64 KB RAM als Luxus betrachteten und entsprechend entwarfen.

Warum es 2026 noch immer läuft

Die naheliegende Frage ist: warum benutzt das noch jemand? Ein paar Gründe, über die niemand Blog-Posts schreibt:

  • Es ist brutal zuverlässig. Das Global-Storage-Modell ist transaktional und crash-safe. MUMPS-Installationen, die seit 30 Jahren ohne Datenverlust- Incident laufen, sind nicht selten; sie sind typisch.
  • Die Code + Data-Kollokation ist eine Performance-Waffe. Moderne Drei-Tier-Architekturen zahlen einen Round-Trip-Preis pro Datenbankzugriff. MUMPS zahlt gar nichts — die Datenstruktur ist buchstäblich von der ausführenden Code-Zeile adressierbar. Für Workloads, die auf kleinen Reads und Writes heißlaufen (Apothekensuchen, Patientenaktenzugriff, Labor-Result- Writes), schlägt es in echten Benchmarks immer noch die meisten Alternativen.
  • Migrationskosten sind erschreckend. Epics Codebase ist seit 40 Jahren gewachsen. Ein vollständiges Rewrite ist kein 18-Monats-Projekt; es ist ein mehrzehnjähriges. Die richtige strategische Frage ist nicht “wann ersetzen wir es?”, sondern “was bauen wir daneben?”

Was ich beim Arbeiten damit gelernt habe

Bei HAKEEM sind wir auf VistA/MUMPS-Komponenten getroffen, weil die öffentliche Health-IT in Jordanien Teile des Open-Source-Healthcare-Stacks der US-Veteranen- behörde übernommen hatte. Bei AFAQ haben wir mit Apothekensystemen integriert, deren Datenschicht MUMPS-nah war. Ich behaupte nicht, ein MUMPS-Experte zu sein — ich habe vielleicht ein paar Tausend Zeilen davon über diese Jahre geschrieben. Was ich behaupte: diese paar Tausend Zeilen haben mir mehr über Datenbankdesign beigebracht als ein Großteil der modernen RDBMS-Arbeit, die ich danach gemacht habe.

Konkret:

  • Subscripted Key-Design zählt mehr als du denkst. Die richtige Schlüssel- Hierarchie zu wählen ist das MUMPS-Äquivalent von Schema-Design. Falsch gemacht, scannen deine Reads zu viel. Richtig gemacht, hast du O(1)-Zugriff auf genau die Bytes, die du willst.
  • Das Cost-Modell ist im Code sichtbar. SET ^patient(id, "name")=value ist eine Disk-Operation. Du kannst das nicht hinter einem ORM verstecken. Das zwingt dich, auf einem Niveau über Datenzugriff nachzudenken, das moderne Sprachen dir ermöglichen zu ignorieren.
  • Global Locks sind ein Feature, kein Bug. Das MUMPS-Locking-Modell ist primitiv — was bedeutet, dass du darüber nachdenken kannst. Modernes verteiltes Locking ist komplex, was bedeutet, dass du das oft nicht kannst.

Die 2026-Version davon

Würde ich heute ein neues Greenfield-Transaktions-Healthcare-System starten, würde ich MUMPS wählen? Nein. Ich würde Postgres mit sorgfältigem Schema-Design und expliziten Transaktionsgrenzen nehmen und ein glücklicheres Leben führen.

Aber ich würde es auch ablehnen, die Codebases zu verspotten, die noch immer MUMPS in Production betreiben. Sie sind tragende Teile von Krankenhaussystemen, die Menschen am Leben erhalten. Die Engineers, die sie warten, sind unverhältnismäßig fähig auf Arten, die moderne Web-Engineers nicht erkennen: Sie verstehen Storage-Kosten auf Byte-Ebene, sie können über jahrzehntealte Invarianten nachdenken, und sie haben eine Beziehung zu ihren Production-Daten, die FAANG-Engineers seit 20 Jahren nicht mehr haben.

Das Pull-Quote

Wenn jemand in deinem Team über eine MUMPS-Codebase lacht, sagt er etwas über sich selbst — nicht über die Codebase. Frag ihn, ob sein letztes Greenfield- Rewrite seit 30 Jahren in Production ist. Wenn die Antwort “nein” ist, ist das Lachen verfrüht.

Der älteste Code, der noch in Production läuft, ist fast immer der Code, über den man sich am wenigsten lustig machen sollte.