Aerospace, defense and energy programs run builds, tests and launch operations on procedure and execution software. Few vendors in the category publish how that software performs under load. Here is the baseline we think every vendor should publish, and our results against it.
A test conductor signing off a step during a hot fire is waiting on a database write. So is a technician closing out a torque sequence on a flight article. At a few hundred milliseconds, nobody notices. At several seconds, the operator starts asking whether the record saved, and the next step waits on the answer.
Vendors building software for hardware write about scalability, uptime and response-time targets. Very few publish their own results: the dataset they tested against, the load they applied and the resource that ran out first. Buyers compare adjectives during the evaluation and learn the real limits after go-live, on a production line or a test stand.
Chipmakers publish benchmark results. AI labs publish scores on standard tests. Software that runs flight hardware, weapons programs and reactor operations should be held to the same standard. We are proposing a baseline, and publishing our own results against it.
The baseline
| Disclosure | What to publish | Epsilon3 |
|---|---|---|
| Dataset | Counts of procedures, steps, runs and attachments in the test environment | 36,253 procedures, 63,853 runs, about 2.47M steps, about 249K attachments |
| Load model | Concurrent load, the workflows it runs, and how test load maps to real users | 500 heavy-use load generators, equal to roughly 5,000 very active users in one workspace |
| Results and limits | How the system responded at peak, and the first resource to run out | Application tier under half its CPU; main database was the limit |
| Cadence | How often the test runs, and whether it grows with customers | Weekly performance tests, monthly full-scale load tests |
| Availability | A public status page with per-environment history | status.epsilon3.io, four production environments |
| Authorization | The federal authorization the production cloud holds, and its level | FedRAMP High since July 2025 |
What the load test showed
Load came from 500 virtual machines running on infrastructure separate from the platform, so generating load never competed with the application for resources. Each machine authored procedures, reviewed them, executed runs, signed off steps and pulled attachments continuously, without the pauses an operator takes to read a step or take a measurement. Each one stands in for several people; together they represent roughly 5,000 very active users working at once in a single workspace.
The workspace held a production-scale dataset: 36,253 procedures averaging 68 steps and 10 sections, 63,853 runs, 166,176 part definitions, 13,279 tool definitions and nearly 249,000 image and document attachments. Step and section totals are estimated from those averages; every other figure is a direct count.
The application tier never came close to its limits. At peak, web servers used under half of their reserved processing capacity and about two-thirds of their memory, with zero restarts and no memory errors.
The main database is where the test found the limit. On a smaller instance, the full load used all of its processing power. Partway through the run we moved to a larger instance through an automated failover that took seconds. The same load then peaked well under half of the new capacity, and response times stayed within our targets for the rest of the test.
That result is the reason to test at program scale. We found the limit in a test, before a customer could find it on a launch day, and we now know exactly where to plan capacity.
Testing that keeps pace
Performance tests run every week to catch regressions from that week's changes. A full-scale load test runs every month at increasing scale, and both the dataset and the simulated load grow as customer workspaces grow. We will publish updated results here as test scale increases, along with write-ups of the architectural changes behind them.
Availability you can check
status.epsilon3.io shows live status and uptime history for our US, FedRAMP, UK and EU production environments separately, with a timeline and resolution for every incident. Anyone can subscribe by email, text, Slack or RSS. Epsilon3 has held FedRAMP High authorization since July 2025, with production in AWS GovCloud (US). With Offline Mode, operators keep executing runs already in progress through a network loss, and the record syncs when the connection returns.
What we are asking
To other vendors serving aerospace, defense, energy and other critical operations: publish a baseline against these six items, date it and update it as you ship. Use your own dataset and your own workflows. The format matters less than the disclosure.
To buyers: put the six items in your RFP and your evaluation plan. Ask for the dataset counts, the load model and how it maps to real users, the first resource to run out and the test cadence. Then bring your longest, most complex procedure and run it during the trial.
Our customers build launch vehicles, aircraft, missile systems, submarines and reactors. The teams running those programs should know how their software behaves at peak load before the peak arrives.
