A public FHIR server benchmark is only as useful as its harness. The new report from Health Samurai compares Aidbox, HAPI FHIR, Medplum, and the Microsoft FHIR Server, and the part worth reading carefully is not the headline numbers but the test harness itself. Procurement and architecture teams evaluating FHIR backends benefit from understanding how the scenario was built, because the harness controls what the numbers actually mean. The benchmark was authored by Marat Surmashev, VP of Engineering at Health Samurai, and the full code is at the open benchmark repository. For more on FHIR APIs for payers, the broader coverage sits in the related hub.
This is a vendor-run benchmark; Health Samurai makes Aidbox. The open harness is what lets a procurement team treat the numbers as a starting point rather than a marketing claim, and the daily CI rerun makes the regression story visible.
The Hardware and Container Layout
The test runs on a single bare-metal host with 64 CPU cores and 500 GB RAM. Each FHIR server receives 8 vCPU and 24 GB RAM. Medplum follows its documented multi-replica deployment and runs 8 replicas of 1 vCPU and 3 GB each. The hardware pinning matters: every server runs under the same ceiling on the same machine, which removes the most common source of unfair benchmark numbers.
The databases also match the production shape for each server. Aidbox, HAPI FHIR, and Medplum run on PostgreSQL 18. The Microsoft FHIR Server runs on SQL Server 2022 Developer Edition because that is its production database. Forcing a single shared backend would have penalized one server unfairly.
The Data: Synthea, 1,000 Patients, ~2 Million Resources
The benchmark loads a Synthea-generated dataset of 1,000 patients, roughly 2 million FHIR resources. Same generation seed, same resource graph across every server. The trade is the obvious one: 1,000 patients fits comfortably in 500 GB of RAM, which means the current snapshot is a clean baseline rather than a stress test. The next post in the series is expected to test at scale.
The CRUD Workload
The CRUD scenario uses Grafana k6 against nine FHIR resource types, with 300 concurrent threads driving create, read, update, and delete operations against each server. Nine resource types is enough to exercise the common write paths in a clinical workflow without the run becoming impossible to interpret. The 300-thread concurrency target is high enough to saturate modest single-container allocations and surface the real tail behavior under contention.
The Bundle Import Workload
Bundle import is its own scenario, with 20 concurrent threads pushing Synthea-generated transaction bundles into each server. Twenty threads is the right neighborhood for an EHR-style backfill: high enough to find contention, low enough to avoid overwhelming the database tier in ways that hide the actual server behavior. For procurement teams evaluating FHIR backends for migration projects, this is often the most relevant scenario in the harness.
The Search Workload
Search runs across all six FHIR search parameter families: string, date, reference, token, quantity, and composite. The benchmark notes that Medplum does not support composite search and that the Microsoft FHIR Server is notably slow on quantity (around 1.2 seconds at P99) and composite (around 1.9 seconds at P99). Running every family rather than cherry-picking the easy ones is what makes the search part of the harness honest.
The Daily CI Rerun
The entire scenario runs on a daily CI schedule, with the dashboard published live. That turns the benchmark into a regression test for every server's release cycle. Anyone watching the daily dashboard can spot when a server version pushes a number up or down. The Medplum CTO has already forked the repo, which is a reasonable open-source response to an open benchmark.
For surrounding coverage on FHIR backends in payer-side contexts, the complete guide to FHIR prior authorization for health plans in 2026 and the FHIR bulk data tools writeup cover the wider FHIR-API picture that any of these servers will sit underneath.