How do you actually compare FHIR servers when every vendor publishes their own throughput chart? A new public report from Health Samurai takes a swing at the question by putting four servers on the same hardware, the same Synthea data, and the same load harness, then publishing the result on a dashboard that reruns every day.
The four servers in the test are Aidbox, HAPI FHIR, Medplum, and the Microsoft FHIR Server. The setup is a single bare-metal machine, 64 CPU cores, 500 GB of RAM, with each server boxed into 8 vCPU and 24 GB of memory. The dataset is Synthea-generated, 1,000 patients, around 2 million resources. Load generation runs through Grafana k6. For more on healthcare data exchange, the broader picture is on the homepage.
What the Numbers Look Like
A few headline figures from the snapshot taken on 2026-06-29:
- CRUD throughput tops out at about 5,200 requests per second on Aidbox. Microsoft sits at the other end of the table, near 440 requests per second.
- Storage footprint after loading the same dataset runs from 6.83 GB on Aidbox to 22.6 GB on HAPI FHIR, with Microsoft at 4.24 GB and Medplum near 11.8 GB.
- Bundle import speed is in the same ballpark for Aidbox and HAPI, with Medplum and Microsoft trailing.
The numbers are attributed to Health Samurai's reporting; the dashboard updates daily, so any single snapshot is just one point on the line.
Why Hardware Parity Matters
The most useful thing about the report is not any one number. It is the design choice to pin every server to identical resources. In most published FHIR benchmarks the hardware quietly changes between rows, which makes the comparison soft. Forcing the four servers onto the same chip and the same memory allocation removes that excuse. The Synthea data is also the same across all four, so the load shape is symmetric.
That said, there is an obvious wrinkle. The benchmark is published by Health Samurai, the company behind Aidbox. The repository is open and the methodology is documented, but the framing of which metrics get emphasized is still a vendor choice. Readers can re-run the harness against their own servers if they want to check.
What It Does Not Tell You
The dataset is small enough to fit in memory. With 1,000 patients and roughly 2 million resources, the database working set is not big enough to test what happens when production workloads spill onto disk or when index sizes get awkward. The accompanying note says the next post in the series will run at scale; until then, the current numbers are a baseline read rather than a production model.
Sites comparing tooling at the application layer often pair this kind of throughput read with workflow concerns; the complete guide to FHIR form tools for US clinics and top 5 SDC form builders for urgent care settings cover the form layer that sits on top of any of these servers.
The honest read of the new benchmark is that it gives the FHIR community a shared, daily, open data point. That is a useful thing to have, even with the caveats attached.