Stata 19 MP oder SE: Paperdaten 2026 richtig wählen

Sie warten bei Bootstrap, Simulationen oder großen Datenaufbereitungen stundenlang, wissen aber nicht, ob der Engpass wirklich Stata ist?

Die schnellste Lösung: Wählen Sie für die meisten Dissertationen zunächst Stata/SE. Wechseln Sie erst zu Stata/MP, wenn Ihre Daten die SE-Grenzen erreichen oder ein repräsentatives do-file bei parallelisierbaren Befehlen nachweislich viel Zeit verliert.

Dieser Beitrag richtet sich an Sie, wenn Sie als Masterstudent, Doktorand oder Lehrender eine Stata-19-Version für eine empirische Arbeit auswählen. Auch Forschungsmitarbeitende mit Regressionen, Simulationen, Bootstrap-Schleifen oder umfangreicher Datenaufbereitung finden hier ein Messverfahren. Labor- und Institutsadministratoren erhalten zusätzlich Prüfpunkte für Lizenzen und gemischte Mac-, Windows- und Linux-Umgebungen.

Starten Sie mit dem tatsächlichen Projektumfang

„Große Datei“ ist keine ausreichende technische Beschreibung. Eine komprimierte Datendatei kann klein wirken und trotzdem sehr viele Variablen enthalten. Umgekehrt kann eine größere Datei mit überschaubarer Struktur problemlos in Stata/SE laufen.

Prüfen Sie deshalb vier Eigenschaften:

• aktuelle Beobachtungszahl und Variablenzahl;
• maximale Variablenzahl nach Wide-Transformationen;
• Zahl der Regressoren, Interaktionen und erzeugten Hilfsvariablen;
• erwartete Erweiterung durch Zusammenführen weiterer Wellen, Simulationen oder Sensitivitätsanalysen.

Die offizielle Vergleichstabelle der Stata-Versionsgrenzen ist dafür die maßgebliche Quelle. Sie unterscheidet die technischen Grenzen von Stata/BE, Stata/SE und Stata/MP. Diese Grenzen sind keine Geschwindigkeitswerte. Eine Datei unterhalb der SE-Grenze wird durch MP nicht automatisch schneller verarbeitet.

Die Kapazitätsprüfung als Stop- oder Wechselpunkt

Wenn Ihr aktueller Datensatz und die geplante Projektstruktur deutlich unter den offiziellen SE-Grenzen bleiben, gibt es keinen sachlichen Grund, allein wegen der Dateigröße MP zu kaufen. Das gilt auch für viele Paneldatenanalysen, sofern das Projekt nicht durch extreme Variablenbreite oder zusätzliche Simulationstabellen wächst.

Anders sieht es aus, wenn Sie bereits beim Import, beim Zusammenführen oder bei der Erzeugung von Zwischenvariablen an eine Versionsgrenze stoßen. Dann ist die Kapazitätsfrage zuerst zu lösen. Eine schnellere CPU ersetzt keine fehlende Datenkapazität.

Prüfkriterium	Stata/SE ist meist ausreichend, wenn …	Stata/MP wird prüfenswert, wenn …
Datenstruktur	Daten und geplante Wide-Form unter den offiziellen Grenzen bleiben	Zusammenführungen, Simulationen oder Umformungen die Grenze berühren
Modell	Übliche Regressionen und Panelmodelle interaktiv laufen	Wiederholte Schätzungen mit vielen Varianten dominieren
Wachstum	Die Dissertation mit dem vorhandenen Datenumfang planbar bleibt	Neue Wellen, Resampling oder künstliche Stichproben vorgesehen sind
Entscheidung	Kein reproduzierbarer Engpass gemessen wurde	Ein Engpass im repräsentativen do-file belegt ist

Der relevante Wert ist also der Spitzenumfang während des gesamten Projekts. Sichern Sie eine kleine Dokumentation: Welche Datei ist maximal breit? Welcher Schritt erzeugt die meisten Variablen? Welche Analyse wird später wiederholt? Diese Notizen sind für die Lizenzentscheidung belastbarer als eine Schätzung anhand der Dateigröße im Finder.

Isolieren Sie die Befehle mit dem größten Parallelisierungspotenzial

Stata/MP ist kein allgemeiner „Turbo-Schalter“. Der Nutzen hängt davon ab, ob ein konkreter Befehl parallel arbeiten kann, wie groß der parallelisierbare Anteil ist und ob Ihre Daten genug Arbeit für mehrere Kerne liefern.

Beginnen Sie nicht mit der Frage, wie viele Kerne Ihr Apple-Silicon-Mac besitzt. Beginnen Sie mit Ihrem do-file. Markieren Sie alle Abschnitte, die regelmäßig Wartezeit erzeugen:

• wiederholte Regressionen in Schleifen;
• Bootstrap- oder Simulationsläufe;
• große Sortier- und Zusammenführungsschritte;
• Berechnung vieler Transformationen;
• Export, Import oder Zugriff auf Dateien im Hochschulnetz.

Datenlesen, Grafikaufbau und Dateizugriffe sind nicht automatisch gute MP-Kandidaten. Ein Teil der Wartezeit kann durch den Datenträger, einen Netzpfad oder die Vorbereitung des Befehls entstehen. In diesem Fall bringt eine höhere Parallelisierung wenig.

Der offizielle Stata/MP-Performancebericht zeigt, welche Befehle in den jeweiligen Tests wie untersucht wurden. Die technische Beschreibung der Stata/MP-Architektur erklärt zusätzlich, dass die Skalierung vom einzelnen Befehl und von der Arbeitslast abhängt. Lesen Sie diese Angaben als Vergleich unter Testbedingungen, nicht als Versprechen für Ihre Dissertation.

Erfahrung aus der Projektprüfung: Wenn nur eine kleine Regression schnell läuft, aber Import, Bereinigung und Ergebnisexport den Großteil der Gesamtzeit ausmachen, ist ein Versionswechsel wahrscheinlich nicht die erste Lösung. Messen Sie den vollständigen Ablauf.

Wie viele Kerne wirklich zählen

Mehr Kerne können einen parallelisierbaren Teil beschleunigen. Sie beschleunigen jedoch nicht den seriellen Teil, Wartezeiten auf Dateien oder Arbeitsschritte, die vom vorherigen Ergebnis abhängen. Bei kleinen Datensätzen kann außerdem der Verwaltungsaufwand der Parallelisierung den Vorteil begrenzen.

Der offizielle PDF-Performancebericht von Stata dokumentiert die ursprünglichen Testbedingungen. Achten Sie beim Lesen auf die verwendeten Befehle, Datenmengen, Hardware und Skalierungsgrenzen. Übertragen Sie eine dort genannte Beschleunigung nicht direkt auf Ihr Projekt.

Eine gute Entscheidungsregel lautet:

• Wenn die langsamsten Befehle nachweislich parallelisierbar sind und häufig wiederholt werden, testen Sie MP.
• Wenn nur einzelne kleine Befehle langsam wirken, prüfen Sie zuerst den Datenaufbau und das do-file.
• Wenn der Ablauf überwiegend Dateien liest oder schreibt, untersuchen Sie Speicherort und Datenträger.
• Wenn die Laufzeit hauptsächlich durch Simulationen entsteht, testen Sie die komplette Schleife und nicht nur eine Einzelschätzung.
• Wenn die Wartezeit nur gelegentlich auftritt, rechtfertigt sie meist keine dauerhafte MP-Lizenz.

Trennen Sie Rechen-, Speicher- und Speicherplatzengpässe

Ein Versionswechsel kann eine CPU-Limitierung adressieren. Er löst aber keinen zu kleinen Arbeitsspeicher, keine häufige Auslagerung und keinen langsamen Netzwerkpfad.

Unterscheiden Sie drei typische Lastprofile:

Lastprofil	Was Sie beobachten sollten	Wahrscheinliche erste Prüfung
Interaktive Analyse kleinerer Ausschnitte	Reaktionszeit bei Befehlen, Grafiken und Variableninspektion	do-file, Datenstruktur und lokale Arbeitskopie
Große Verarbeitung im Arbeitsspeicher	Speicherbelegung, Auslagerung und Abbruchmeldungen	Arbeitsspeicherbedarf und Variablenreduktion
Viele Importe und Exporte	Dateidauer, Netzwerkaktivität und Zugriffsfehler	lokaler Datenträger, Netzpfad und Dateiformat

Stata/MP kann auch dann unter seinen Möglichkeiten bleiben, wenn macOS bereits Daten aus dem Arbeitsspeicher auslagert. Ebenso kann eine Projektablage auf einem Netzlaufwerk jede CPU-Beschleunigung verdecken. Legen Sie für den Test eine anonymisierte Arbeitskopie lokal ab. Dokumentieren Sie, ob die Verzögerung beim Start, bei der Bereinigung, bei der Schätzung oder beim Export entsteht.

Für sensible Forschungsdaten ist der Speicherort eine eigene Entscheidung. Entfernen Sie direkte Identifikatoren, prüfen Sie Zugriffsrechte und halten Sie die Vorgaben Ihrer Hochschule sowie der DSGVO ein. Eine Remote-Mac-Umgebung ist kein automatischer Datenschutzfreibrief. Sie müssen klären, ob die Daten in ein externes Rechenzentrum übertragen werden dürfen, wie Backups funktionieren und wer Zugriff auf die Maschine erhält.

Prüfen Sie Lizenz, Betriebssystem und Teamgrenzen

Stata 19 ist laut offizieller Dokumentation als MP-, SE- und BE-Variante verfügbar. Die offizielle Seite zu kompatiblen Betriebssystemen ist für die aktuell unterstützten Plattformen maßgeblich. Für Apple Silicon bestätigt Stata den Mac-Betrieb in der Mac-Unterstützung für Apple-Silicon-Systeme.

Das bedeutet für Ihre Auswahl:

• Apple Silicon ist kein ausreichender Grund, MP statt SE zu wählen.
• Die Wahl der Version und die Wahl des Betriebssystems sind getrennte Fragen.
• Ein do-file sollte auf Mac, Windows und Linux dieselben Datenpfade, Pakete und Ausgabeformate nachvollziehbar verwenden können.
• Eine Plattformlizenz bedeutet nicht automatisch, dass ein einzelnes Konto von beliebig vielen Personen gleichzeitig verwendet werden darf.

Prüfen Sie zuerst beim Softwarezentrum, bei der Bibliothek oder bei der IT-Abteilung Ihrer Hochschule, welche Lizenz Ihr Institut bereits besitzt. Die offiziellen Bildungs- und Hochschullizenzoptionen helfen bei der Einordnung. Vertragsbedingungen, autorisierte Nutzende, Remote-Zugriff und gleichzeitige Nutzung müssen Sie mit der zuständigen Stelle klären. Diese Hinweise ersetzen keine Vertragsprüfung.

Für einen Lehrstuhl mit gemischten Geräten ist SE oft organisatorisch einfacher, wenn alle Beteiligten das Projekt mit derselben Version ausführen können. MP kann fachlich sinnvoll sein, aber nur, wenn die Lizenz den geplanten Nutzungsweg abdeckt und Betreuende sowie Koautoren die Ergebnisse ebenfalls prüfen können.

Sichern Sie die Reproduzierbarkeit vor dem Geschwindigkeitsgewinn

Eine Dissertation wird nicht nur auf Ihrem Rechner bewertet. Ihr Betreuer, ein Koautor, ein Gutachter oder ein späteres Teammitglied muss die zentralen Ergebnisse nachvollziehen können.

Vergleichen Sie bei SE und MP deshalb nicht nur die Endzeit einer Regression. Prüfen Sie:

• identische Rohdaten und identische Prüfsummen;
• gleiche Paketversionen und gleiche do-file-Reihenfolge;
• reproduzierbare Pfade ohne persönliche Benutzerverzeichnisse;
• vollständige Logs und gespeicherte Ergebnisdateien;
• identische Zufallsinitialisierung bei Simulationen und Bootstrap;
• Verhalten bei Abbruch, Wiederaufnahme und Teilergebnissen.

Die offizielle Stata-Seite zu Mac-Systemen und Plattformunterstützung bestätigt die plattformübergreifende Ausrichtung. Das allein beweist jedoch nicht, dass jedes Projekt ohne Anpassung reproduzierbar ist. Dateipfade, Zeichencodierung, externe Pakete und lokale Betriebssystemrechte bleiben mögliche Fehlerquellen.

Wenn Sie ohne eigenen Mac arbeiten, kann ein zeitlich begrenzter Remote-Test sinnvoll sein. MACCOME stellt eine echte Remote-Mac-Umgebung mit Zugriff über VNC, SSH oder eine Webkonsole bereit. So können Sie eine anonymisierte Projektkopie ausführen, ohne sofort ein Gerät dauerhaft anzuschaffen. Hinweise zu geeigneten Mac-Mietmodellen für wissenschaftliche Arbeitsumgebungen finden Sie auf der deutschsprachigen Übersichtsseite.

Führen Sie einen kontrollierten Versionsvergleich durch

Nutzen Sie für die Entscheidung einen kleinen, aber repräsentativen Durchlauf. Die folgenden Schritte lassen sich mit einer anonymisierten Kopie umsetzen:

• Projektumfang festhalten: Sichern Sie die aktuelle Variablen- und Beobachtungsstruktur sowie die erwarteten Erweiterungen.
• do-file aufteilen: Markieren Sie Start, Import, Bereinigung, Kernschätzung, Simulationen, Export und Protokollierung.
• Messpunkte einbauen: Notieren Sie den Beginn und das Ende jedes großen Abschnitts. Messen Sie die gesamte Projektlaufzeit.
• Umgebung vereinheitlichen: Verwenden Sie dieselben Daten, Pakete, Pfade und Zufallsinitialisierungen in SE und MP.
• Ressourcen beobachten: Prüfen Sie Arbeitsspeicher, Auslagerung, CPU-Auslastung, Datenträgeraktivität und Netzwerklast.
• Ergebnisse vergleichen: Kontrollieren Sie Fehlermeldungen, Koeffizienten, Standardfehler, Logs und exportierte Tabellen.
• Wiederholung durchführen: Lassen Sie den langsamsten repräsentativen Abschnitt mehrmals laufen, statt aus einem Einzelstart zu schließen.
• Entscheidung dokumentieren: Schreiben Sie auf, welcher Engpass MP rechtfertigt oder warum SE genügt.

Ihr Entscheidungsbaum

• Wenn die Datenstruktur die offiziellen SE-Grenzen erreicht oder überschreitet, wählen Sie MP nur nach Prüfung der konkreten Lizenz und Projektkompatibilität.
• Wenn die Daten unter den SE-Grenzen bleiben, aber wiederholte Kernbefehle den größten Zeitanteil bilden und im offiziellen Bericht parallelisierbar sind, testen Sie Stata/MP mit Ihrem do-file.
• Wenn der MP-Test die Gesamtwartezeit nicht spürbar verbessert, bleiben Sie bei SE oder beheben Sie zuerst Speicher-, Datei- und Netzwerkengpässe.
• Wenn Ihr Institut bereits eine passende MP-Lizenz für alle berechtigten Nutzenden besitzt, prüfen Sie die technische Umsetzung statt vorschnell neue Hardware zu kaufen.
• Wenn die Umgebung oder Lizenz unklar ist, verwenden Sie zunächst einen kurzfristigen Remote-Mac-Test mit anonymisierten Daten.
• Wenn Koautoren oder Prüfende nur SE zuverlässig ausführen können und die Daten dort funktionieren, priorisieren Sie die gemeinsame Reproduzierbarkeit gegenüber einem isolierten Geschwindigkeitsgewinn.

Bewerten Sie Kauf, vorhandene Geräte und Remote-Zugriff

Ein eigener Mac ist sinnvoll, wenn Sie dauerhaft lokal arbeiten, physische Anschlüsse benötigen oder über Jahre hinweg eine stabile persönliche Umgebung aufbauen. Für eine einzelne Dissertation oder eine kurze Methodenphase kann der Kauf dagegen Kapital binden, obwohl die MP-Leistung gar nicht benötigt wird.

Ein Hochschulserver ist attraktiv, wenn die Daten dort bereits liegen und Linux- oder Windows-Werkzeuge den Hauptteil der Analyse übernehmen. Er ersetzt aber keine macOS-Prüfung, wenn Sie die Mac-Version von Stata, bestimmte Pakete oder eine plattformübergreifende Ausgabe validieren müssen.

Die Miete einer Remote-Mac-Umgebung passt besonders zu einem begrenzten Testfenster, einem einzelnen Projektabschnitt oder fehlender lokaler Hardware. Über MACCOME für einen zeitlich begrenzten Mac-Zugriff können Sie die tatsächliche Umgebung prüfen, bevor Sie eine langfristige Beschaffung oder Lizenzänderung beantragen. Verwenden Sie dabei nur Daten, deren Übertragung und Verarbeitung organisatorisch freigegeben ist.

Häufige Fragen zu Stata 19 MP und SE

Die folgenden Antworten trennen Kapazität, Laufzeit und Umgebung. Damit vermeiden Sie die häufige Fehlentscheidung, aus dem Namen des Prozessors direkt auf die passende Stata-Version zu schließen.

Treffen Sie die Entscheidung für Ihre Dissertation

Für die meisten normalen empirischen Arbeiten ist Stata/SE der vernünftige Ausgangspunkt. Wenn Sie Daten nahe an den offiziellen Grenzen verarbeiten oder häufige, nachweislich parallelisierbare Befehle ausführen, kann Stata/MP die richtige Wahl sein. Der entscheidende Nachweis ist jedoch ein repräsentatives do-file unter realen Bedingungen.

Der derzeitige Ansatz hat drei typische Schwächen: Ein vorhandener Hochschulrechner kann beim macOS-Test fehlen, gemeinsam genutzte Geräte lassen sich nicht immer kurzfristig reservieren, und ein vorschneller Hardware- oder Lizenzkauf bindet Budget ohne belegten Laufzeitgewinn. Wenn Sie diese Unsicherheit für einen begrenzten Projektabschnitt vermeiden möchten, ist die Miete eines Remote Mac über MACCOME die pragmatische Zwischenstufe: Sie testen Kompatibilität, Ressourcen und Wartezeit mit Ihrer eigenen anonymisierten Aufgabe und entscheiden danach über SE, MP oder eine dauerhafte Ausstattung.

Wenn Sie jetzt eine Testumgebung für Ihr Stata-Projekt benötigen, prüfen Sie bei MACCOME die verfügbaren Mietzeiträume und wählen Sie zunächst den kürzesten Zeitraum, der einen vollständigen repräsentativen Durchlauf einschließlich Export und Reproduzierbarkeitsprüfung erlaubt.