bonfireDB vs Medplum
Medplum gives you a complete, production-proven FHIR R4 platform — auth, access policies, subscriptions, Bots, terminology, a React library — and the trade is that you adopt FHIR as your application data model. bonfire bets the other way: typed clinical app primitives, fresh-on-commit reads, a reactive cache, and ABAC-enforced hybrid search up front, with canonical FHIR R4 underneath — but it is largely vision today, not a shipped, certified platform.
TL;DR
Medplum is the strongest open-source FHIR-native developer platform available: Apache-2.0 core, ONC-certified Health IT module, strongly-consistent Postgres search, fine-grained access policies, WebSocket subscriptions, and real production use at publicly cited customers like Thirty Madison and Summer Health. If you want a battle-tested clinical backend and are happy to model your domain in FHIR, Medplum is hard to beat today. bonfire is positioned for the founder who wants an app-database feel — typed clinical projections, a Convex-style reactive cache, built-in ABAC-enforced hybrid search, and agent context tools over clean read models — with canonical FHIR R4 underneath rather than the thing you program against. The honest caveat: bonfire is early-stage and its column here describes design intent, while Medplum’s column describes shipped, certified, at-scale software.
At a glance
Medplum is the mature, ONC-certified FHIR-native backend you build a clinical app on; bonfireDB is an earlier-stage, app-first clinical layer with canonical FHIR R4 underneath instead of asking you to model everything as FHIR.
| Medplum | bonfireDB | |
|---|---|---|
| Type | Open-source FHIR-native developer platform (“headless EHR”) | Agent-native clinical backend; canonical FHIR R4, typed reads on top |
| Language / stack | TypeScript end-to-end; Node + Postgres + Redis | TypeScript + Postgres + pgvector |
| License / cost | Apache-2.0 core (free self-host); managed cloud — see vendor pricing (verify current pricing, 2026) | Planned Apache-2.0 core + managed tier |
| Hosting | Managed cloud or self-host on your AWS (~0.5 FTE ops) | Designed for your AWS or managed |
| App-native typed API | Partial — FHIR-native + generated types; supports user-defined SearchParameters, but no custom resource types (use Basic/extensions) | By design — typed clinical primitives |
| Fresh-on-commit app reads | Yes — strongly consistent; writes immediately searchable | By design — committed operational read models |
| Reactive realtime cache | Partial — Subscriptions + useSubscription hook; no auto-reactive query cache | By design — useClinicalQuery |
| Built-in semantic search | No built-in vector/semantic search; DIY on Postgres | By design — built in — hybrid (BM25 + vector), ABAC-enforced |
| Agent / MCP layer | Yes — official MCP endpoint plus a $ai operation, AI Bots, and an in-app AI assistant (Spaces); generic FHIR access rather than cited evidence packets (verify current docs) | By design — agent-native: context tools over cited evidence packets; ABAC-enforced read + aggregate (design-intent), targeting the raw-FHIR context/evidence bottleneck measured in FHIR-AgentBench |
| Clinical authorization (write-enforced) | Yes — Access Policies, ABAC criteria, compartments, write constraints | By design — read + write enforced ABAC, auto-audit |
| Automatic audit / provenance | Partial — full FHIR AuditEvents, but REST capture needs logAuditEvents enabled | Automatic by design |
| FHIR conformance / export | FHIR R4 native, US Core, ONC (g)(10) certified; $everything/Bulk export | Canonical FHIR R4 (JSONB), typed reads on top; scoped conformance (honest: not a full enterprise FHIR server) |
| Best for | Teams wanting a mature, certified FHIR platform to build on | Builders of AI-native health apps (scribes, copilots, agents) |
Where Medplum genuinely wins
- FHIR-native from the ground up with generated TypeScript types for every resource (@medplum/fhirtypes) — strong compile-time safety and no translation layer for a TS/React team.
- ONC-certified Health IT Module against the (g)(10) SMART/Bulk-Data criteria, with a Standard BAA on paid cloud tiers — a real, documented compliance head start.
- Strongly-consistent search: values are extracted via FHIRPath and written in the same transaction as the resource, so a write is immediately searchable — no eventual-consistency lag (bonfire claims NO advantage here).
- Genuinely complete backend out of the box: auth, FHIR store, REST + GraphQL, access policies, Bots, subscriptions, terminology service, an MCP server (shipped June 2025), on-prem HL7v2/DICOM Agent, and a React component library — you don’t assemble a dozen services.
- Sophisticated, purpose-built authz: per-resource/per-interaction Access Policies, criteria-based ABAC filtering, compartments, element-level hidden/readonly fields, FHIRPath write constraints, and break-glass.
- Real production proof at scale (publicly cited customers include Thirty Madison, Summer Health, and the CDC) on a boring, proven Postgres + Redis stack, with both managed-cloud and self-host paths.
Where bonfireDB is built different
- App-state as a first-class typed primitive. Medplum supports user-defined SearchParameters, but not custom resource types — non-FHIR/app-specific data must be shoehorned into Basic resources or extensions, and the guidance is to model everything as FHIR. bonfire’s design exposes typed clinical projections plus a home for app/draft state so you don’t fight the FHIR data model or stand up a second DB.
- A Convex-style reactive query cache. Medplum ships WebSocket Subscriptions and a useSubscription hook, but no auto-normalizing reactive query cache — you wire subscription events to refetches/state yourself. bonfire’s design makes useClinicalQuery results update reactively without manual subscription plumbing.
- Built-in, ABAC-enforced hybrid search. Medplum’s search is Postgres-only with no built-in vector/semantic search; any RAG/embedding layer is DIY on top. bonfire’s design bakes hybrid search (BM25 + vector) in and enforces ABAC on every hit.
- A production-intended agent layer. As of mid-2026 Medplum’s MCP server exposes a generic fhir-request tool (search/fetch tools are proposed upstream, not yet merged), with enforcement inherited from its AccessPolicy layer — genuine governance, and honest credit for it. Its broader AI surface also includes a $ai operation, AI Bots, and the Spaces in-app assistant. The difference is the payload and the proof: generic FHIR access vs. bonfire’s query-aware cited evidence packets, plus the aggregate-level ABAC bonfire is building — with the measurement program public. No FHIR-server MCP ships that combination today, and bonfire’s is pre-release.
- Audit on by default rather than opt-in. Medplum produces full FHIR-native AuditEvents, but RESTful audit capture requires enabling the logAuditEvents server setting. bonfire’s design emits audit/provenance automatically on every enforced read and write with no config flag.
- App-first ergonomics without learning FHIR to ship. Medplum requires learning the FHIR data model, search params, and profiles to be productive. bonfire’s design lets a founder program against clinical primitives and export conformant FHIR R4 on demand.
Which should you choose?
Choose Medplum if…
Choose Medplum if you need a mature, ONC-certified, production-proven FHIR platform today, are comfortable modeling your domain in FHIR, and want the broadest conformance, ecosystem, and a clear self-host-or-managed path with real reference customers.
Choose bonfireDB if…
Choose bonfire if you’re a founder shipping an outpatient or AI-native healthcare app and want app-database ergonomics — typed primitives, reactive reads, built-in ABAC-enforced hybrid search, and query-aware agent context — with canonical FHIR R4 underneath, and you can accept an early-stage product whose conformance breadth is intentionally scoped, not a full enterprise FHIR server.
You build the app. Bonfire is the clinical data layer underneath.
Early access. Designed to run in your AWS — open-source core planned (Apache-2.0) — with the clinical layer handled.
Frequently asked questions
bonfireDB vs Medplum: what’s the real difference?
Medplum is a mature, ONC-certified FHIR-native platform where you model your domain in FHIR. bonfireDB is an earlier-stage, app-first clinical backend that exposes typed clinical primitives and a reactive cache, with canonical FHIR R4 underneath. bonfireDB is largely design intent today; Medplum is shipped, certified, at-scale software.
Is Medplum a good choice for a clinical backend?
Yes, if you’re comfortable modeling your domain in FHIR. As of 2026, Medplum offers an Apache-2.0 core, ONC (g)(10) certification, strongly-consistent Postgres search, fine-grained access policies, and real production use at publicly cited customers like Thirty Madison and Summer Health. Verify current capabilities before deciding.
What does Medplum lack that bonfireDB is designed to add?
Medplum has no built-in vector/semantic search (it’s DIY on Postgres), no auto-reactive query cache (you wire subscriptions to refetches yourself), and no custom resource types — app-specific data goes into Basic resources or extensions. bonfireDB is designed for ABAC-enforced hybrid search, a Convex-style reactive cache, and typed app primitives. Verify Medplum’s current state with its docs.
Is there a Medplum alternative with app-database ergonomics?
bonfireDB is positioned as that alternative: typed clinical projections, fresh-on-commit reads, a reactive cache, and built-in ABAC-enforced hybrid search, so you program against clinical primitives instead of learning FHIR to ship. It’s early access — its column describes design intent, not certified at-scale software like Medplum.
Does bonfireDB or Medplum have a better FHIR MCP / agent layer?
Medplum ships an MCP server (as of mid-2026: a generic fhir-request tool, enforcement inherited from AccessPolicy; search/fetch tools are proposed upstream, not yet merged), plus a $ai operation, AI Bots, and an in-app AI assistant. bonfireDB’s design differs on the payload: query-aware cited evidence packets rather than generic FHIR access, plus the aggregate-level ABAC bonfire is building (pre-release), with a public measurement program — targeting the context/evidence bottleneck measured in our FHIR-AgentBench fork.