Stata 19: Welche Version wählen? Hochschul-Forschungsleitfaden 2026

Das Projekt startet, aber bei Datenumfang, Lizenz oder Mehrkernbedarf ist unklar, ob die vorhandene Stata-Version ausreicht.

Schnellentscheidung: Wählen Sie nicht allein wegen eines Mehrkernprozessors Stata/MP. Prüfen Sie zuerst Daten und Modelle, danach den tatsächlichen Parallelisierungsbedarf. Reicht die bereits lizenzierte Version aus und ist keine parallele Berechnung erforderlich, behalten Sie sie zunächst bei.

Dieser Leitfaden richtet sich an Studierende und Promovierende, die Stata auf einem Mac für Lehrveranstaltungen oder Forschungsarbeiten einsetzen.
Forschende und Projektleitungen können damit Auswahlkriterien für gemeinsame Analyseabläufe festlegen.
Hochschul-Support und Lizenzverantwortliche erhalten eine Trennung zwischen Versionswahl, Lizenzprüfung und macOS-Umgebung.

Die Versionswahl folgt Daten-, Rechen- und Reproduzierbarkeitskriterien

Die Entscheidung lässt sich auf drei Prüfbereiche reduzieren: Daten- und Modellgrenzen, Parallelisierbarkeit und Reproduzierbarkeit. Danach folgen Lizenz und Betriebssystem. Die Stata-Dokumentation unterscheidet Stata/BE, Stata/SE und Stata/MP. Die Bezeichnungen stehen für unterschiedliche Einsatzbereiche und Begrenzungen, nicht für eine pauschale Rangliste, in der jede Forschungsarbeit automatisch die leistungsstärkste Ausgabe benötigt. Die offizielle Übersicht zur Auswahl der Stata-Version beschreibt die Positionierung dieser drei Ausgaben.

Die zentrale Frage lautet daher nicht „Welche Version ist die beste?“, sondern „Welche Grenze meines konkreten Projekts wird von der aktuellen Ausgabe erreicht?“ Ein Datensatz kann sich öffnen lassen, während ein späterer Modellschritt dennoch an einer Grenze scheitert. Umgekehrt bedeutet eine größere mögliche Kapazität nicht, dass eine Analyse dadurch schneller oder wissenschaftlich belastbarer wird.

Vor der Auswahl sollte die Projektleitung eine kurze Anforderungsliste erstellen:

• größte tatsächlich verwendete Datendatei und Zahl der benötigten Variablen,
• Modelltypen und deren unabhängige Variablen,
• Befehle oder Schleifen, die den größten Anteil der Laufzeit beanspruchen,
• vorhandene Campus- oder Einzellizenz und deren erlaubte Nutzung,
• macOS-Version und verwendeter Mac-Typ,
• Kriterien, anhand derer Ergebnisse nach einem Versionswechsel verglichen werden.

Diese Liste verhindert zwei häufige Fehlentscheidungen: eine Ausgabe nur nach dem Namen zu wählen oder ein Lizenzproblem mit einem technischen Versionsproblem zu verwechseln.

Die Unterschiede zwischen Stata/BE, Stata/SE und Stata/MP

Die offizielle Dokumentation ordnet die drei Ausgaben nach den jeweils verfügbaren Kapazitäten und Rechenmöglichkeiten ein. Stata/BE ist für Analysen vorgesehen, deren Daten- und Modellanforderungen innerhalb der Grenzen dieser Ausgabe liegen. Stata/SE bietet erweiterte Kapazitäten, wenn beispielsweise mehr Variablen oder größere Modelle benötigt werden. Stata/MP ergänzt Mehrkernberechnung für unterstützte Analyseabläufe. Die verbindlichen Grenzwerte sind in der offiziellen Vergleichstabelle der Versionslimits aufgeführt.

Prüfen Sie dort nicht nur die Zahl der Beobachtungen. Relevant sein können auch Variablen, Matrixdimensionen und die Anforderungen des verwendeten Schätzverfahrens. Die Bezeichnungen „BE“, „SE“ und „MP“ ersetzen keine Prüfung der für den konkreten Befehl geltenden Grenzen.

Auch die Reihenfolge der Prüfung zählt. Wenn das Modell mit der lizenzierten Ausgabe nicht ausführbar ist, hilft eine schnellere Verarbeitung nicht weiter. Wenn das Modell ausführbar ist, aber die Laufzeit problematisch ist, kann Mehrkernunterstützung relevant werden – vorausgesetzt, der verwendete Arbeitsablauf profitiert davon.

Datenkapazität und Modellanforderungen getrennt prüfen

Die Datenkapazität sollte anhand der vollständigen Analyse beurteilt werden, nicht nur anhand des Imports. Ein Datensatz kann vollständig eingelesen werden, doch ein Modell kann zusätzliche Variablen, Zwischenergebnisse oder größere Matrizen benötigen. Deshalb sind „Datei lässt sich laden“, „Befehl lässt sich ausführen“ und „Forschungsaufgabe lässt sich abschließen“ drei verschiedene Prüfungen.

Erstellen Sie zunächst eine Kopie oder eine anonymisierte Stichprobe des Projektdatensatzes. Ermitteln Sie dann, wie viele Variablen der Analysepfad tatsächlich benötigt. Bei zusammengeführten Dateien, Indikatorvariablen und erzeugten Variablen kann diese Zahl vom ursprünglichen Datensatz abweichen. Notieren Sie außerdem, welche Modelle, Interaktionen oder Robustheitsprüfungen in der Arbeit verbindlich vorgesehen sind.

Gleichen Sie die Werte anschließend mit den Einträgen für Beobachtungen, Variablen und relevante Modellgrenzen in der offiziellen Versionsübersicht ab. Übernehmen Sie Grenzwerte nicht aus einem alten Skript oder einer informellen Empfehlung. Die offiziellen Limits sind die Referenz für den Vergleich der Ausgaben.

Ein häufiger Denkfehler ist, die notwendige Version allein aus der Größe einer Datei abzuleiten. Dateigröße und benötigter Arbeitsspeicher sind keine zuverlässigen Ersatzwerte für die Versionsgrenzen. Ebenso reicht die Zahl der Zeilen nicht aus, wenn das Modell an einer anderen Grenze scheitert. Die Auswahl sollte deshalb für den anspruchsvollsten vorgesehenen Arbeitsschritt erfolgen, nicht für den einfachsten Import.

Datenumfang und Modellvariablen als Auswahlkriterien

Datenumfang und Modellanforderungen beeinflussen die Versionswahl. Wenn ein Datensatz oder ein Modell eine Grenze der aktuell lizenzierten Ausgabe überschreitet, muss eine Ausgabe mit ausreichender Kapazität geprüft werden. Ob dafür Stata/SE oder Stata/MP erforderlich ist, hängt von der konkreten Grenze ab, die für die Analyse zählt. Es wäre ein Fehlschluss, aus „größere Daten“ automatisch „Mehrkernversion“ abzuleiten: Kapazität und Parallelisierung sind getrennte Kriterien.

Fehlt eine belastbare Angabe, prüfen Sie zunächst einen realistischen Projektabschnitt mit der bestehenden Ausgabe. Dokumentieren Sie, an welchem Schritt die Verarbeitung endet, welche Fehlermeldung erscheint und welche Modellanforderung betroffen ist. Eine Stichprobe kann bei dieser Diagnose helfen, ersetzt aber nicht die abschließende Prüfung mit den tatsächlichen, freigegebenen Daten.

Prüfen Sie die Anforderungen an einer freigegebenen Projektkopie. Forschungsdaten mit Personenbezug oder vertraglichen Zugriffsbeschränkungen gehören nicht ohne Zustimmung in eine neue Umgebung oder auf einen nicht genehmigten Rechner.

Mehrkernverarbeitung anhand des Analyseablaufs bewerten

Ein Mac mit mehreren Prozessorkernen ist für sich genommen kein Grund, Stata/MP zu wählen. Der Mehrkernzugriff kann nur bei Befehlen und Arbeitsabläufen helfen, die von Stata dafür unterstützt werden. Die offizielle Beschreibung von Stata/MP erläutert dessen Ausrichtung auf Mehrkernverarbeitung. Der offizielle Leistungsbericht für Stata/MP zeigt zugleich, dass Leistungsaussagen an konkrete Befehle und Testbedingungen gebunden sind.

Das bedeutet für Hochschulprojekte: Die Anzahl der Kerne im Gerät ist kein Ersatz für einen Test der eigenen Analyse. Ein Do-File kann überwiegend aus Datenbereinigung, Ein-/Ausgabe, einzelnen nicht parallelisierten Befehlen oder externen Wartezeiten bestehen. In solchen Fällen sagt die Prozessorkonfiguration allein wenig über einen möglichen Zeitgewinn aus.

Wählen Sie einen repräsentativen Analyseabschnitt, der in der regulären Arbeit tatsächlich viel Zeit beansprucht. Verwenden Sie dieselben Eingabedaten, dieselbe Modellformel und dieselben Ausgabeschritte. Erfassen Sie die Laufzeit unter dokumentierten Bedingungen, aber behandeln Sie einen einzelnen Test nicht als allgemeingültigen Leistungsnachweis. Wird ein Unterschied festgestellt, sollte die Messung mit einem vergleichbaren Lauf überprüft werden.

Mehrkernversion bei gewöhnlichen Regressionen

Eine gewöhnliche Regression ist kein hinreichender Grund, Stata/MP zu wählen. Entscheidend ist, ob die verwendeten Befehle und der konkrete Analyseablauf von der Mehrkernverarbeitung profitieren und ob die gemessene Laufzeit für das Projekt ein relevantes Problem darstellt. Die offiziellen Informationen zu Stata/MP und der Leistungsbericht sollten deshalb zusammen mit einem Test der eigenen Befehle gelesen werden.

Für ein Kursprojekt mit überschaubarer Laufzeit kann eine bereits lizenzierte Ausgabe ausreichen, sofern Daten und Modelle innerhalb ihrer Grenzen liegen. Bei wiederholten Schätzungen, umfangreichen Robustheitsläufen oder langen Auswertungsroutinen lohnt sich ein repräsentativer Vergleich. Er liefert eine bessere Entscheidungsgrundlage als die Annahme, dass jede Analyse auf einem Mac mit mehreren Kernen automatisch schneller sein muss.

Notieren Sie für diesen Test den verwendeten Befehl, die Datengrundlage und die Einstellungen der Umgebung. Ändern Sie nicht gleichzeitig die Datenaufbereitung, den Modellaufbau und die Version. Sonst ist bei einem abweichenden Ergebnis nicht mehr klar, welche Änderung dafür verantwortlich war.

Reproduzierbarkeit nach einem Versionswechsel dokumentieren

Ein Versionswechsel kann die Laufzeit oder einzelne numerische Ausgaben beeinflussen. Die offizielle FAQ zu Ergebnissen in unterschiedlichen Stata-Versionen und zur Mehrprozessorberechnung beschreibt, warum bei bestimmten iterativen Schätzverfahren Unterschiede auftreten können, etwa durch Prozessoranzahl oder Berechnungsreihenfolge. Das ist ein Prüfhinweis, keine Behauptung, dass sich nach jedem Wechsel Ergebnisse ändern.

Für die wissenschaftliche Übergabe ist deshalb wichtig, neben dem Ergebnis auch die Umgebung zu dokumentieren. Dazu gehören die verwendete Stata-Ausgabe, das Betriebssystem, der Prozessoreinsatz, das Do-File und die relevanten Dateneingaben. Wenn möglich, sollten Original- und Zielumgebung mit derselben freigegebenen Projektkopie getestet werden.

Ein einfaches Protokoll kann so beginnen:

log using "versionspruefung.log", text replace
about
display c(os)
do "analyse_kern.do"
log close

Die konkrete Ausgabe von about und display c(os) hängt von der laufenden Umgebung ab. Der Ausschnitt ist daher kein vorweggenommenes Prüfergebnis, sondern eine Vorlage, um Stata- und Betriebssysteminformationen gemeinsam mit dem Analyseprotokoll festzuhalten. Ergänzen Sie das Do-File um die für Ihr Projekt relevanten Schätzungen und Exporte. Sichern Sie das Protokoll so, dass es später zusammen mit der Projektkopie ausgewertet werden kann.

Vergleichen Sie anschließend nicht nur die letzte Bildschirmzeile. Prüfen Sie die zentralen Schätzer, Standardfehler, Konvergenzmeldungen, Fallzahlen und erzeugten Dateien. Falls sich Werte unterscheiden, untersuchen Sie zunächst, ob Eingaben, Einstellungen und Ausführungsbedingungen wirklich identisch waren. Bei methodisch relevanten Abweichungen sollte die Projektleitung festlegen, welche Umgebung als Referenz gilt, und die Entscheidung im Analyseprotokoll begründen.

Versionswechsel und mögliche Ergebnisabweichungen

Bei iterativen Schätzverfahren können sich Ausgaben durch Prozessoranzahl oder Berechnungsreihenfolge im Detail unterscheiden. Daraus folgt nicht, dass jeder Wechsel von Stata/SE zu Stata/MP Ergebnisse verändert. Es bedeutet, dass die betreffenden Ergebnisse bei einem Versions- oder Umgebungstest geprüft und dokumentiert werden sollten.

Führen Sie das zentrale Do-File in einer Projektkopie aus und vergleichen Sie die wesentlichen Schätzer, Standardfehler und erzeugten Dateien. Halten Sie fest, ob die Daten, Befehle und Einstellungen identisch waren. Werden Unterschiede sichtbar, untersuchen Sie zunächst die Berechnungsbedingungen und nicht nur die angezeigte Zahl. Die offizielle FAQ zu abweichenden Ergebnissen bietet dafür den passenden technischen Hintergrund.

Lizenz und macOS-Kompatibilität als eigene Prüfpunkte behandeln

Die Versionswahl beantwortet nicht, ob eine konkrete Hochschullizenz die Nutzung auf einem bestimmten Rechner erlaubt. Lizenztyp, berechtigter Nutzerkreis, Installationsbedingungen und Nutzung außerhalb des Campus müssen bei der zuständigen Stelle geprüft werden. Lassen Sie sich bestätigen, ob die vorhandene Lizenz für die gewünschte Stata-Ausgabe und den vorgesehenen Rechner gilt. Ein technischer Start der Software ist kein Nachweis für eine genehmigte Nutzung.

Auch das Betriebssystem ist ein eigener Prüfpunkt. Stata dokumentiert die kompatiblen Betriebssysteme und führt dort macOS-Versionen bis macOS 26 auf. Daraus lässt sich keine Aussage zur Unterstützung eines späteren Systems ableiten; prüfen Sie die aktuelle offizielle Liste vor der Installation erneut. Für Apple-Silicon-Macs erklärt Stata gesondert, dass Stata 19 nativ laufen kann: maßgeblich ist die offizielle Auskunft zur Ausführung auf Apple Silicon.

Damit sind drei Fragen getrennt zu beantworten:

• Version: Reichen Daten- und Modellgrenzen der lizenzierten Ausgabe?
• Lizenz: Erlaubt die Hochschule die Nutzung dieser Ausgabe auf der vorgesehenen Maschine?
• Umgebung: Sind Mac-Typ und macOS-Version laut aktueller Stata-Dokumentation unterstützt?

Die offizielle Mac-Installationsanleitung ist für die Einrichtung relevant. Sie ersetzt jedoch weder die Lizenzbestätigung noch die Freigabe für Forschungsdaten. Bei einer externen oder gemieteten Umgebung sollten Forschende zusätzlich klären, ob die Datenverarbeitung den Vorgaben der Hochschule, der DSGVO und möglichen Projektvereinbarungen entspricht. Prüfen Sie insbesondere Datenminimierung, Zugriffsrechte, Übertragung, Speicherort und Löschung. Verwenden Sie für eine erste Kompatibilitätsprüfung bevorzugt anonymisierte oder anderweitig freigegebene Daten.

Entscheidungshilfe und Prüfschritte für das Hochschulprojekt

Die Entscheidung sollte zuerst eine geeignete Ausgabe festlegen und erst danach die Frage beantworten, wo die Analyse laufen soll. Diese Reihenfolge bewahrt vor unnötigen Ausgaben für eine leistungsfähigere Lizenz, die das eigentliche Problem – etwa eine fehlende Hochschulgenehmigung oder eine nicht unterstützte Umgebung – nicht löst.

Gehen Sie folgendermaßen vor:

1. Lizenzbestand ermitteln. Fragen Sie die zuständige Hochschulstelle, welche Ausgabe freigegeben ist und wer sie auf welchen Geräten verwenden darf. Dokumentieren Sie die Antwort.
2. Projektanforderungen erfassen. Notieren Sie die größte vorgesehene Datenmenge, die benötigten Variablen und die anspruchsvollsten Modelle. Berücksichtigen Sie Zwischenschritte und erzeugte Variablen.
3. Grenzen offiziell abgleichen. Vergleichen Sie die Anforderungen mit den Einträgen für Stata/BE, Stata/SE und Stata/MP in der offiziellen Grenzwertübersicht. Halten Sie fest, welche konkrete Grenze für die Auswahl ausschlaggebend ist.
4. Rechenbedarf separat testen. Führen Sie einen repräsentativen, freigegebenen Analyseabschnitt aus. Ein Mehrkernprozessor allein begründet keine Umstellung auf Stata/MP.
5. Ergebnisbasis sichern. Protokollieren Sie Software- und Betriebssysteminformationen, Do-File, Eingabedaten und zentrale Resultate. Vergleichen Sie nach einem Wechsel die relevanten Ausgaben.
6. macOS und Datenfreigabe bestätigen. Prüfen Sie die aktuelle Kompatibilitätsliste sowie die Regeln Ihrer Hochschule für Lizenz, Zugriff und Forschungsdaten.
7. Erst dann über eine neue Umgebung entscheiden. Wenn kein geeigneter Mac verfügbar ist, testen Sie zunächst mit einer genehmigten, anonymisierten Projektkopie. Eine neue Maschine löst weder ein Lizenzproblem noch fehlende Datenschutzfreigaben.

Nutzen Sie zusätzlich diese Entscheidungsliste:

• [ ] Daten und Modelle passen in die vorhandene Ausgabe: Die lizenzierte Version bleibt zunächst bestehen.
• [ ] Eine offizielle Kapazitätsgrenze wird erreicht oder überschritten: Prüfen Sie, welche Ausgabe die benötigte Grenze abdeckt, statt allein nach dem Kürzel MP zu wählen.
• [ ] Die Kapazität reicht, aber die Analyse dauert zu lange: Testen Sie einen repräsentativen Arbeitsablauf, bevor Sie Mehrkernverarbeitung als notwendig einstufen.
• [ ] Ein Versionswechsel zeigt abweichende Ergebnisse: Vergleichen Sie Daten, Einstellungen und Berechnungsbedingungen und dokumentieren Sie die Referenzumgebung.
• [ ] Lizenz oder Datenfreigabe ist ungeklärt: Verschieben Sie den Test mit nicht anonymisierten Forschungsdaten, bis die verantwortliche Hochschulstelle die Nutzung bestätigt hat.

Eine temporäre Mac-Umgebung als Prüfoption

Wenn ein Labor ausschließlich Windows- oder Linux-Rechner bereitstellt, lässt sich damit nicht abschließend prüfen, ob ein Analyseablauf in der vorgesehenen macOS-Umgebung korrekt funktioniert. Ein eigener Mac kann für eine kurzfristige Kompatibilitätsprüfung unverhältnismäßig sein, wenn das Gerät anschließend kaum genutzt wird. Umgekehrt ist eine temporäre Umgebung nicht die passende Dauerlösung, wenn das Projekt langfristig hohe Rechenlast, lokale Schnittstellen oder dauerhaft kontrollierte Hardware benötigt.

Für einen begrenzten Testzeitraum kann ein gemieteter Mac eine Option sein: Führen Sie darin nur freigegebene Testdaten aus, bestätigen Sie zuvor Lizenz und Zugriff und vergleichen Sie die Ergebnisse mit der dokumentierten Referenzumgebung. Die verfügbaren Mietoptionen und Konditionen sollten vorab geprüft werden; aktuelle Angaben finden Sie auf der Seite zu Mac-mini-Mietpreisen. Der Überblick zu den Mac-Angeboten kann helfen, die passende Zugriffsform für den geplanten Test zu bestimmen.

Für eine kurzzeitige Prüfung kann SFTPMAC damit einen zugänglicheren Weg bieten, als allein für einen Versionsvergleich sofort Hardware anzuschaffen. Vor der Nutzung bleiben die Hochschullizenz, die Verarbeitung sensibler Daten und die projektspezifische Freigabe zu klären. Wer dauerhaft rechenintensive Analysen ausführt oder besondere physische Anschlüsse benötigt, sollte stattdessen prüfen, ob ein eigener, institutionell verwalteter Mac oder eine andere genehmigte Infrastruktur besser passt.