Four open-source Apex suites — 837 tests — run twice: once against a real Salesforce org, once against Nimbus. Every suite passes completely in both arms, so nothing separates the two columns except how long you sit there. The org column includes the deploy, because on an org you cannot run a test you have not deployed yet.
Time from pressing enter to having results in hand, split into the two things an org makes you wait for. Linear scale — the Nimbus bars really are that short.
Median of three runs each. Deploy and test are listed apart so you can discount the deploy if your workflow somehow doesn't have one.
| Suite | Tests | Org deploy | Org tests | Org total | Nimbus | Factor |
|---|---|---|---|---|---|---|
| apex-test-kitTest-data factory — DML across standard objects | 87 | 5.3s | 21.3s | 26.6s | 0.59s | 45× |
| sobject-fabricatorIn-memory SObject fabrication, relationship trees | 124 | 5.6s | 17.3s | 22.9s | 0.47s | 49× |
| trigger-actions-frameworkTrigger dispatch, custom metadata, order of execution | 155 | 12.3s | 16.5s | 28.8s | 0.52s | 55× |
| fflib-apex-mocksMocking framework — stubs, matchers, verification | 471 | 7.4s | 20.4s | 27.8s | 0.70s | 40× |
| All four | 837 | — | — | 106.1s | 2.3s | 47× |
Each phase is the median of its three runs; the org total is those two medians added. Test counts are identical in both arms and every run in both arms was green — the same tests, not a subset.
A full-suite run is the number people quote, but it isn't the number that decides how a day feels. That one is the inner loop: change one class, push it, run its tests, read the failure, change it again.
We measured it — one edited class, deployed on its own, one test class of 124 tests, three times through. On the org that cycle costs 18.9 seconds (5.3s to deploy the single file, 13.5s to get results). On Nimbus the same cycle is 1.09 seconds.
Seventeen times less, repeated every few minutes, is the difference between staying in a problem and going to make coffee while a deployment finishes.
# On an org: deploy, then wait for the queue
sf project deploy start -d classes/MyThing.cls
sf apex run test --class-names MyThingTest --wait 30
# 18.9s
# With Nimbus: the source is already the input
nimbus test MyThingTest
# 1.09sA benchmark you can't reproduce is an advertisement. Here is everything you need to run it yourself, including the parts that don't flatter us.
Four open-source repositories, unmodified: ApexTestKit, sobject-fabricator, trigger-actions-framework, and fflib-apex-mocks. They were chosen because Nimbus passes them completely and the org passes them completely, which is what makes the timing the only variable. Test counts match arm to arm.
A Salesforce Developer Edition org on API 67, driven by Salesforce CLI 2.147.7. Wall clock from pressing enter to results in hand: sf project deploy start for the deploy, then sf apex run test with --wait. The deploy counts because the org cannot run source it hasn't been given.
The same source on disk, run warm — the project's embedded PostgreSQL already up, which is how it sits during a working session. The first run in a fresh project pays a one-time 6.2 seconds to initialise the database and build the schema; after that the same suite runs in 0.4 seconds. No org connection, no network.
Apple M2, 8 cores, macOS 26.5.1, on a domestic connection. Every figure is the median of three runs. Org timings move with pod load and time of day; a busy sandbox is slower than this DE org, not faster.
Point Nimbus at your project and time the first warm run yourself.
brew install nimbus-solution/nimbus/nimbus
cd your-sfdx-project
nimbus test "*"