The official Stata limits table lists a maximum of 3,276 variables for Stata/SE and 65,536 for Stata/MP. Check the current version limits before planning a large thesis dataset.

Symptom → Your ordinary regressions run normally, but a wide panel, repeated bootstrap job, or simulation keeps you waiting.

Fastest fix → Choose Stata/SE unless your project approaches its official capacity limit or its slowest repeated commands are demonstrably helped by parallel execution. Do not choose Stata/MP only because an Apple Silicon Mac has more CPU cores.

Who should read this guide

This guide is for graduate students and researchers choosing a Stata 19 edition while controlling software and hardware costs.

It also fits researchers running regressions, simulations, bootstrap procedures, or large data transformations, plus lab administrators standardizing licenses across Mac, Windows, and Linux systems.

The decision is not “which edition has the better specification?” It is “which edition removes the bottleneck in your actual research workflow?”

Start with the data shape, not the file size

A compressed data file can look small while becoming much wider after merges, reshaping, dummy-variable generation, or intermediate calculations. File size is therefore a weak first filter.

Inspect these dimensions instead:

  • Number of observations after all planned merges.
  • Number of variables in the widest stage of the do-file.
  • Number of model covariates, indicators, interactions, and generated terms.
  • Extra columns created for lags, leads, weights, imputation, or simulation.
  • Expected growth if you append future survey waves or administrative records.

Stata/SE is usually the sensible choice when the project stays comfortably below its official limits. The relevant question is not whether today’s .dta file opens. It is whether the widest intermediate dataset will remain valid after the thesis analysis is complete.

The official comparison page is the authority for current limits. Do not copy a limit from an old forum answer or from a lab workstation configured for an earlier release. Stata 19 includes MP, SE, and BE editions, but their capacity boundaries are not interchangeable.

A capacity decision rule

Choose Stata/SE when:

  • Your current and planned intermediate datasets remain below the official SE limits.
  • You can complete merges, reshapes, and model preparation without dropping required variables.
  • Your problem is slow storage, insufficient memory, or network access rather than a version ceiling.

Move to Stata/MP when:

  • A required data structure genuinely exceeds the SE limit.
  • The project’s future peak shape is known and cannot be redesigned without compromising the analysis.
  • A representative test shows that MP solves the blocking step rather than merely changing the edition label.

Do not upgrade for capacity based only on a large raw file. First identify the widest and most memory-intensive point in the pipeline.

First metric: measure the command that actually waits

Stata/MP is not a universal speed switch. Its benefit depends on whether a particular command can use multiple cores, how much of the task can run in parallel, and how much time is spent outside that command.

Separate the do-file into timed stages:

  • Data import and conversion.
  • Cleaning, sorting, merging, and reshaping.
  • Feature generation and panel preparation.
  • Core estimation.
  • Bootstrap, simulation, or permutation loops.
  • Graphics and table production.
  • Export to documents or spreadsheets.

The official Stata/MP performance report provides measured results for selected commands and test conditions. Its figures describe those tests. They do not promise the same acceleration for your data, processor, storage, operating system, or command sequence.

For command-level detail, compare the official Stata/MP performance information. Look for the commands that account for most of your elapsed time, not the commands that sound computationally impressive.

A short regression that runs in seconds does not justify MP by itself. A bootstrap or simulation routine repeated many times may deserve testing, but only if the expensive portion is implemented in a way that can benefit from parallel execution.

What more cores cannot fix

More cores will not automatically solve:

  • A slow network-mounted project directory.
  • Repeated import and export of large files.
  • Frequent sorting caused by inefficient data preparation.
  • Memory pressure that triggers swapping.
  • A serial command surrounded by parallel-ineligible steps.
  • Interactive delays caused by remote desktop latency.

The correct metric is total workflow time. A single estimation command can become faster while the complete do-file remains almost unchanged.

Use memory and storage as separate tests

Version selection often fails because the researcher measures CPU time but ignores waiting caused by memory and storage.

For an in-memory analysis, check whether the machine can hold the working dataset and temporary objects without constant pressure. If the system starts swapping, a faster edition may not produce a useful improvement. The edition does not create additional physical memory.

For a file-heavy workflow, inspect:

  • Where raw and intermediate files are stored.
  • Whether the project runs from local storage or a mounted network path.
  • How often the do-file reads and writes data.
  • Whether compressed archives are unpacked during each run.
  • Whether logs and result files are written to a remote location.

For an interactive workflow, observe how the delay feels. A local-looking interface can still pause when the remote host waits for storage or when your connection adds latency. This matters when you inspect variables, correct errors, or rerun only one section of a do-file.

Match the bottleneck to the workload

Workload pattern Evidence to collect Likely first choice
Small or moderate interactive dataset Peak memory, command errors, local response time Stata/SE
Large in-memory panel or wide intermediate table Maximum variables, observations, memory pressure, failed steps SE if within limits; MP if the structure exceeds SE
Repeated bootstrap, simulation, or expensive estimation Elapsed time by command, repeat count, official parallel-performance evidence Benchmark SE and MP
Frequent import, export, sorting, or network file access Read/write time, storage location, total do-file duration Fix I/O first; do not assume MP will help

The table is a triage tool, not a performance guarantee. Stop the upgrade decision if the evidence points to storage or memory. Changing editions before correcting the bottleneck adds license complexity without addressing the wait.

Check platform support and license scope before changing machines

Stata’s official Apple Silicon guidance confirms support for Stata on Macs using Apple Silicon. Verify the current Mac compatibility guidance and the supported operating systems page before committing a remote or local environment.

The practical consequence is straightforward: Apple Silicon is a platform choice, not proof that MP is required. A supported processor does not make every Stata command parallel, and a larger core count does not remove data limits or license restrictions.

Before ordering or installing anything, ask your software center:

  • Does the university agreement include Stata/MP, or only SE?
  • Is your access personal, departmental, campus-wide, or laboratory-specific?
  • Can an authorized user access the installation through a remote host?
  • Does the license allow the intended number of users?
  • Are Mac, Windows, and Linux installations covered under the same terms?
  • What happens when a student leaves the institution or the license renews?

Stata states that its licenses are not restricted to one operating system, but that does not mean one account can be shared freely by multiple people. Read the education license options and ask the institution to interpret its own agreement. This article gives you a verification path, not legal advice or a replacement for the contract.

Protect reproducibility before chasing speed

A thesis workflow must survive handoff. Your adviser, coauthor, replication reviewer, and defense computer may not use the same edition or operating system.

Compare the following before selecting MP:

  • Does the do-file open and run with the target edition?
  • Does the data structure stay below the collaborator’s edition limits?
  • Are logs, estimation results, and exported tables identical?
  • Are random seeds and simulation settings controlled?
  • Does parallel execution alter ordering, timing, or result review?
  • Can another researcher reproduce the output without your remote session?
  • Are all user-written packages and external dependencies documented?

The Stata Mac product information can help confirm the cross-platform context. Still, platform support is not the same as project reproducibility. You must test the actual data, commands, package versions, and output files.

A good lab policy is to define the minimum edition required by the project, then document why. If every member can run the project in SE, standardizing on MP may create unnecessary cost and administrative work. If a key project exceeds SE limits or has a proven MP-dependent workload, record that requirement in the repository and license plan.

Build a representative thesis test before you upgrade

Do not benchmark a single regression selected because it runs quickly. Create a small but representative acceptance task.

Use this sequence:

  1. Copy a de-identified dataset that preserves the relevant width, panel structure, missingness, and grouping patterns.
  2. Extract a do-file segment covering import, cleaning, transformations, the main estimation, repeated procedures, and result export.
  3. Remove credentials, personal data, restricted identifiers, and unrelated files.
  4. Run the task in Stata/SE and record startup, data preparation, core estimation, export completion, errors, and total elapsed time.
  5. Repeat the same task in Stata/MP with the same data, seed, package versions, storage location, and logging settings.
  6. Record peak memory, CPU behavior, disk activity, remote interaction quality, and any output differences.
  7. Inspect the logs and exported results line by line before treating a faster run as successful.
  8. Repeat the test after changing only one relevant variable, such as local versus network storage or SE versus MP.
  9. Stop when the evidence identifies the bottleneck and the result is stable across representative runs.
  10. Choose the least expensive edition that meets the capacity, completion-time, and reproducibility requirements.

This test also works if you do not own a Mac. You can prepare the project locally and validate the macOS path through an authorized remote environment. If your institution has not assigned a target machine, you can review remote Mac access options from MACCOME and treat the session as a controlled compatibility test rather than as an assumption about performance.

Experience note: Keep the test data structurally realistic but legally safe. A tiny synthetic file can hide the memory, sorting, and I/O behavior that controls the real thesis workflow.

Apply the final choice with explicit conditions

Use this decision sequence after the test:

  • If the project stays within Stata/SE limits and MP does not materially improve the complete representative do-file, choose Stata/SE.
  • If the project exceeds an SE capacity limit, choose Stata/MP or redesign the data structure only after confirming that the redesign preserves the research method.
  • If a repeated command is the dominant cost and official documentation plus your test show meaningful MP benefit, choose Stata/MP when the license cost and deployment scope are acceptable.
  • If memory pressure dominates, fix the machine, dataset, or storage path before changing editions.
  • If network access dominates, move the working files or improve the connection before interpreting CPU results.
  • If the adviser or replication environment only supports SE, keep the project runnable in SE unless MP is genuinely required by capacity.
  • If you cannot access the target edition yet, use a short-term remote Mac validation run before requesting a long-term purchase or license upgrade.

This is why most coursework and ordinary thesis analysis should start with SE. MP becomes the defensible choice when a measurable constraint makes it necessary, not when a product page lists more cores.

FAQ: resolve the common selection doubts

Is Stata/SE enough for a graduate thesis?

For most conventional thesis datasets, it is enough when the widest intermediate data structure stays within the official SE limits and the slowest commands do not show a meaningful MP benefit. Test future merges, reshapes, and generated variables. A project that fits today may not fit after adding another wave or expanding a simulation.

Which Stata MP commands can use multiple cores?

Only specific commands and workloads can benefit, and the degree varies. Use the official performance report to identify relevant command evidence. Then time the same command inside your own do-file. Data preparation, graphics, import, export, and file access may remain the dominant cost even when the main estimator supports parallel work.

Does Stata MP run faster with more cores?

Not automatically. The result depends on parallelizable work, memory bandwidth, storage, command implementation, and the amount of serial work around the estimator. Treat the advertised performance figures as results from defined test systems. Compare full workflow completion, not only the fastest line in the log.

Can you test a Stata 19 thesis project without owning a Mac?

Yes, provided the remote environment is authorized and the project data is safe to use there. Run a de-identified acceptance task and compare errors, logs, results, resource pressure, and elapsed time. Confirm the license scope first. A remote test validates compatibility and workflow behavior; it does not replace institutional approval.

Make the environment decision after the evidence

If your current Linux or Windows setup already runs the project within SE limits, has adequate memory, and gives collaborators a repeatable path, replacing it with a Mac may add migration work without improving the thesis.

The weaknesses of the current setup become real when it cannot provide the required macOS environment, forces you to borrow a lab machine, blocks access during shared hours, or makes cross-platform verification impossible. Buying a Mac solves ownership and local access, but it also creates an upfront hardware cost and a device that may sit idle between analysis periods.

For a short compatibility check, a teaching module, or a concentrated revision phase, renting a remote Mac from MACCOME’s Mac access options can be the more controlled experiment. You can validate the same de-identified dataset, compare Stata/SE with Stata/MP where licensed, and measure real waiting time before requesting a permanent purchase. If your university requires a physical interface, long-term heavy use, or offline work, owning approved hardware remains the better fit.