Picking an open-source FHIR server in 2026 is less about "which one has more features" and more about which tradeoffs your team can operate. The three that have real production footprint — HAPI FHIR JPA Server, Medplum, and LinuxForHealth FHIR Server — solve different problems, and picking wrong burns 6-9 months you don't get back.
HAPI FHIR JPA Server
HAPI (v7.x line as of mid-2026) is the veteran choice — Smile CDR's open core, JPA-backed on Postgres or MySQL, R4/R5 support, mature $graphql and terminology server extensions. Best fit: teams that need R4 conformance with heavy SearchParameter customization, or that expect to swap the open version for Smile CDR commercial support later. The rough edges live in bulk export tuning and the operational cost of the JPA layer for high-write workloads — see the HAPI operations guide for the recommended Postgres index tuning that most out-of-the-box deployments miss.
Medplum
Medplum (v3.x) is the more modern choice — TypeScript-native, React-first admin UI, documented subscription/reactivity model, and out-of-the-box support for CDS Hooks and SMART on FHIR. Best fit: healthcare startups building a patient-facing app who want the FHIR backend + auth + admin UI as one stack, and teams that write in TypeScript already. The tradeoff: less battle-tested at very high resource counts (100M+ Observations), and terminology server is minimal versus HAPI.
LinuxForHealth FHIR Server
LinuxForHealth is the IBM-lineage server, Java-based, documented around integration with Cloud Object Storage for bulk data and PostgreSQL/Db2 for OLTP. Best fit: enterprise health systems already on IBM or Red Hat stack, or teams that need FHIR + HL7v2 gateway (LinuxForHealth ships one) in the same platform. Community activity is lower than HAPI in 2026 but the codebase is production-hardened.
Decision matrix
| Signal | HAPI JPA | Medplum | LinuxForHealth |
|---|---|---|---|
| Language ecosystem | Java | TypeScript | Java |
| Auth/SMART | Add-on | Built-in | Add-on |
| Bulk export perf | Good (with tuning) | Fair | Good |
| Terminology server | Full ($expand, $translate) | Minimal | Basic |
| Community size (2026) | Largest | Growing | Stable, small |
| Best for | R4 conformance-heavy | Modern app stack | Enterprise integration |
The FHIR Server Benchmark project publishes side-by-side numbers on all three under identical workloads, which is worth reading before you commit — headline performance is not usually the deciding factor once you weight operator cost and ecosystem fit.
Open-source FHIR is genuinely production-ready in 2026 for all three servers above. The question isn't "which is best" — it's which tradeoffs match how your team ships software and what your patient population's query patterns look like a year in.