Every FHIR server vendor claims R4 conformance, US Core support, and SMART on FHIR. The differences that actually matter are operational, not feature-list. Four criteria cover most of the decision space.
1. Bulk export sustained throughput. Bulk Data IG $export is table-stakes, but sustained NDJSON emission rate at 10M+ resources varies significantly. Aidbox and Medplum both scale cleanly; HAPI JPA scales with careful Postgres tuning; the Microsoft FHIR Server has known throughput ceilings on Cosmos DB backends.
2. Terminology server co-location. Every write triggers $validate-code. In-process terminology (HAPI's module, Aidbox's built-in) beats network-attached (Ontoserver in a separate deployment) by 20-50ms per write. At 10k writes/hour, that's real production latency.
3. Subscription reliability. FHIR Subscription requires reliable delivery with retry, dead-letter, and back-pressure. Aidbox and Medplum ship this natively; HAPI needs external message infrastructure; some servers don't support Subscription at all.
4. Operational observability. Prometheus metrics per resource type is the modern expectation. Aidbox and Medplum expose this natively; HAPI exposes JMX metrics that need a bridge.
Vendor decision matrix (mid-2026)
| Server | Bulk export perf | Terminology | Subscription | Metrics |
|---|---|---|---|---|
| HAPI JPA 7.x | Good (with tuning) | In-process | External | JMX |
| Aidbox 2409 | Excellent | In-process | Built-in | Prometheus |
| Medplum 3.x | Excellent | Minimal | Built-in | OpenTelemetry |
| Microsoft FHIR Server | Fair | External | Add-on | Azure Monitor |
| InterSystems IRIS for Health | Excellent | Enterprise | Enterprise | Enterprise |
SMART on FHIR launch conformance is universal across the top four; don't use it as a selection criterion. Everything meaningful happens at the operational layer.