Four FHIR Servers, Same Hardware: What a New Public Benchmark Just Revealed

Four FHIR Servers, Same Hardware: What a New Public Benchmark Just Revealed

Picking a FHIR server for a US EHR development project usually starts with a vendor deck and ends with a long argument about which set of numbers to trust. On June 29, that conversation changed shape. Health Samurai released a public benchmark that runs four FHIR servers on identical hardware, with the source on GitHub and the dashboard rerunning daily.

The four servers under test are HAPI FHIR, Medplum, the Microsoft FHIR Server, and Aidbox. Every server got the same slice of one large bare-metal machine, the same Synthea dataset, and the same k6 load generator. For US EHR teams that have been trying to compare these vendors against each other without a level playing field, the report fills a gap that has been open for years.

The Hardware Story

The host is a single bare-metal box with 64 CPU cores and 500 GB of RAM. Each server received 8 vCPU and 24 GB of RAM. Medplum runs as 8 single-core replicas with 3 GB each, which matches the way the platform scales in production.

PostgreSQL 18 sits under Aidbox, HAPI, and Medplum. The Microsoft FHIR Server runs against SQL Server 2022 Developer Edition, since that is its native pairing. The intent is to test each server on the database it ships with, not to handicap any of them with a foreign backend.

CRUD Throughput on the June 29 Run

The CRUD test exercises create, read, update, and delete across nine FHIR resource types. The numbers from the snapshot:

  • Aidbox: about 5,212 RPS
  • HAPI FHIR: about 3,058 RPS
  • Medplum: about 1,420 RPS
  • Microsoft FHIR Server: about 440 RPS

The headline takeaway for US EHR teams is the spread. There is an 11x gap between the top and bottom servers on the same hardware, which is the kind of gap that shapes infrastructure cost as soon as a production load lands. Whether your stack faces an ambulatory clinic or a Medicare Advantage plan, that spread shows up on the AWS bill.

Bundle Import for Migration Projects

The bundle import test is what data-migration teams actually feel. Health Samurai reports resources per second during a sustained Synthea bundle ingest:

  • Aidbox: about 2,678 res/sec
  • HAPI FHIR: about 2,214 res/sec
  • Medplum: about 764 res/sec
  • Microsoft FHIR Server: about 448 res/sec

HAPI sits within striking distance of Aidbox here, which tracks with the long history of HAPI investment in batch ingest paths. For a US EHR development team planning a USCDI migration, the import number predicts how long the cutover window has to be. The full configuration and the k6 scripts live in the public benchmark repo for anyone who wants to re-run it locally.

Search and Storage Are Where the Numbers Get Interesting

Search throughput tells a different story than CRUD. Aidbox lands around 3,404 RPS, Medplum around 1,796, HAPI around 1,005, and Microsoft around 261. The benchmark notes that Medplum does not implement composite search and that Microsoft is very slow on quantity and composite parameters, which matters for any EHR development workflow that leans on those families.

Storage on the same 2 million-resource dataset is also worth noting. Microsoft uses 4.24 GB, Aidbox 6.83 GB, Medplum 11.8 GB, and HAPI 22.6 GB. The benchmark explains the spread: HAPI, Medplum, and Microsoft pre-build search indexes on write, while Aidbox ships without default indexes. That choice cuts storage and import time, with the understanding that the operator decides which indexes to add. There is no magic in any of those numbers, just different defaults.

What Reruns Daily Add to the Conversation

For US EHR development teams used to evaluating FHIR servers against a static vendor PDF, the daily public rerun changes the trust model. If Medplum optimizes search and the next day's number jumps, the dashboard shows it. If HAPI ships a new release and the throughput shifts, that shows up too. For the FHIR development collection and the wider US-healthcare framing, the open data point is more useful than another marketing comparison.

The complete guide to FHIR-based EHR development in 2026 covers how to slot a FHIR server choice into a Cures Act program. For teams sizing the cloud bill that follows, top 5 cloud FHIR platforms for EHR modernization walks through the deployment options.

What the Caveat Section Says

The benchmark team is direct about the boundaries of the current run. The Synthea dataset of 1,000 patients and roughly 2 million resources fits in memory on a 500 GB host, which makes this an in-memory test rather than a disk-bound one. For US EHR teams running consolidated patient indexes that already exceed that size, the next number to wait for is the larger-scale follow-up the team has signaled. The current run is still useful for sanity-checking vendor claims. The honest read is that this snapshot is a baseline, not a verdict.