bonfireDB vs HAPI FHIR: App Backend vs FHIR Server

TL;DR

HAPI FHIR is a 12-year-old, Apache-2.0 Java/JPA FHIR server: full CRUD/search/history/validation/$export, subscriptions, terminology, partitioning, and a battle-tested AuthorizationInterceptor — it is the de-facto FHIR reference implementation and the safe choice if you need broad, proven FHIR conformance. It is a FHIR data store and toolkit, not an application framework: there is no app scaffolding, no typed clinical SDK, no native semantic/vector search, and no agent/LLM layer — all of that is yours to build alongside it. bonfireDB inverts the priority: it is positioned as an app-native, TypeScript/Postgres backend with typed clinical primitives, reactive queries, and built-in ABAC-enforced semantic search, generating FHIR underneath rather than starting from it. The honest tradeoff: HAPI is mature and conformant today but heavy and DIY for app builders, while bonfire is early-stage and largely vision, trading conformance breadth for developer velocity on outpatient and AI-healthcare apps.

At a glance

HAPI FHIR is the mature, conformant open-source FHIR engine; bonfireDB is an early-stage app-native clinical backend that generates FHIR underneath — this compares a data store you build on against a framework you build with.

	HAPI FHIR	bonfireDB
Type	Open-source FHIR server + toolkit (data store, not an app framework)	Agent-native clinical backend; FHIR generated underneath
Language / stack	Java / JPA-Hibernate, Spring Boot, Lucene or Elasticsearch	TypeScript + Postgres + pgvector
License / cost	Apache-2.0, $0 license; you run infra/ops, or pay Smile CDR	Apache-2.0 core (free) + managed tier
Hosting	Self-host (Docker/Tomcat) by default; managed only via commercial Smile CDR	Your AWS (OSS) or managed
App-native typed API	No — FHIR data store; build your typed app layer yourself	Yes — typed clinical primitives
Fresh-on-commit app reads	Partial — yes for structured search (ACID relational); full-text index is async unless forced	Yes — committed operational read models
Reactive realtime cache	Partial — Subscriptions (REST-hook/WebSocket/topic), but no app-native reactive cache hook	Yes — useClinicalQuery
Built-in semantic search	No native vector/embeddings; full-text keyword only (_content/_text :contains)	Built in — pgvector, ABAC-enforced
Agent / MCP layer	None native — no MCP or LLM/agent layer; entirely DIY	Build-your-own-MCP over clean projections
Clinical authorization (write-enforced)	Yes — AuthorizationInterceptor enforces request and response; no built-in authentication	Yes — Read + write enforced ABAC, auto-audit
Automatic audit / provenance	Optional automatic AuditEvents via BALP interceptor once registered	Automatic
FHIR conformance / export	Native FHIR-first: DSTU2-R5, full REST, $export; certs only via commercial Smile CDR	FHIR R4 generated underneath; scoped conformance (honest: not a full enterprise FHIR server)
Best for	Teams needing proven, broad FHIR conformance with Java/DevOps capacity	Builders of AI-native health apps (scribes, copilots, agents)

Where HAPI FHIR genuinely wins

Most mature and battle-tested open-source FHIR implementation — ~12 years old, actively released, and the engine behind the public FHIR reference/test server (hapi.fhir.org), with production deployments holding 100M+ resources; the safe choice for proven conformance. (Verify the current release version before you cite it.)
Exceptional FHIR breadth: DSTU2/2.1, STU3, R4, R4B, and R5 in a single codebase, with full REST CRUD/search/history/versioning, transaction bundles, $export bulk export, and validation out of the box — no coding to stand up a compliant server.
Genuine realtime via subscriptions: REST-hook, WebSocket, and R5 topic-based (SubscriptionTopic) notifications, plus email and message-queue channels.
First-class terminology server: CodeSystem/ValueSet/ConceptMap with $expand and $validate-code, and SNOMED CT / LOINC loading via hapi-fhir-cli.
Mature authorization primitives: the AuthorizationInterceptor + RuleBuilder enforce compartment/resource/instance-scoped allow-deny rules on BOTH the request and the response (it aborts if rules forbid returning data) — write-enforced, not read-only.
Built-in automatic audit option: the BALP interceptor auto-generates IHE Basic-Audit-Log-Pattern AuditEvent resources for server activity once registered; plus partitioning/multitenancy, DB-agnostic JPA persistence, and a credible commercial escape hatch in Smile CDR — the supported distribution that adds certifications, BAA, and enterprise support on top of the same engine (verify its current compliance posture before relying on it).

Where bonfireDB is built different

App-native, typed clinical primitives in TypeScript: bonfire is designed as a framework you build WITH, not a FHIR data store you build ON — HAPI ships no app scaffolding, no typed clinical SDK, and no UI, so on OSS HAPI the entire application layer is still yours to assemble.
Native semantic / vector search: HAPI has zero native embeddings or vector search — full-text is keyword-only (Lucene/Elasticsearch _content/_text with a :contains substring modifier). bonfire's design puts pgvector semantic search in the core, scoped by ABAC. (Honest: this is a real HAPI gap; bonfire's is design-stage.)
Built-in agent / MCP layer over clean projections: HAPI contributes nothing toward agent-nativeness — no MCP, no LLM integration, no agent tooling. bonfire positions a build-your-own-MCP surface over typed projections as a first-class concern.
App and draft state as a first-class citizen: a FHIR server like HAPI models FHIR resources, not your app's operational/draft/UI state — teams typically run a second database for it. bonfire's design makes app-state a native home so you don't run two stores. (Honest: app-state-first-class is bonfire positioning, not yet shipped.)
Native stack fit for TypeScript/Python teams: HAPI is a JVM/Spring/Hibernate footprint you must run, tune, and operate (plus a separate Lucene/Elasticsearch cluster for full-text and large-ValueSet $expand) — heavy for a small Node/TS or Python team that doesn't otherwise want a Java server. bonfire targets that stack directly (TypeScript + Postgres).
Integrated, framework-level developer ergonomics: reactive query hooks (useClinicalQuery) and automatic audit/ABAC wired into the data layer, versus HAPI's correct-but-DIY assembly of subscription matcher + channel/broker infra, interceptor wiring, and a separately-bolted-on identity layer (HAPI has NO built-in authentication). (Honest: bonfire's reactive layer is design-stage, not a shipped, benchmarked feature.)

Which should you choose?

Choose HAPI FHIR if…

Choose HAPI FHIR if you need proven, broad FHIR conformance today — multiple FHIR versions, real subscriptions, a full terminology server, multitenancy, and a credible certified/supported upgrade path (Smile CDR) — and you have the Java/DevOps capacity to run and tune a JVM FHIR server (plus Elasticsearch) and build your app, identity, and any AI layer on top.

Choose bonfireDB if…

Choose bonfireDB if you're a small TypeScript/Python team shipping an outpatient or AI-healthcare app and want app-native typed primitives, reactive reads, and ABAC-enforced semantic search out of the box — and you accept that bonfire is early-stage with deliberately scoped (not full enterprise) FHIR conformance, with FHIR generated underneath rather than as the starting point.

bonfireDB is early-stage; this compares its design and positioning against HAPI FHIR as it ships today (2026). Verify current HAPI FHIR capabilities before deciding.

FAQ

Frequently asked questions

HAPI FHIR vs bonfireDB: what's the actual difference?

HAPI FHIR is a mature, conformance-first FHIR data store and toolkit you build ON; bonfireDB is an app-native TypeScript/Postgres clinical backend you build WITH, generating FHIR R4 underneath. HAPI gives you broad, proven FHIR conformance; bonfireDB is designed to give you typed clinical primitives, reactive reads, and ABAC-enforced semantic search. bonfireDB is early access and design-stage on several of these.

Do I need a FHIR server like HAPI for my app?

Not necessarily. HAPI is the right call if you need broad, proven FHIR conformance today (multiple FHIR versions, subscriptions, a terminology server) and have Java/DevOps capacity. If you're a small TypeScript or Python team shipping an outpatient or AI-healthcare app, bonfireDB is designed to be the app backend that sits above the FHIR layer so you don't stand up and tune a JVM server yourself.

Is there a HAPI FHIR alternative for TypeScript teams?

bonfireDB is positioned as exactly that: TypeScript + Postgres + pgvector instead of HAPI's Java/JPA/Spring stack plus a separate Lucene/Elasticsearch cluster. It targets Node/TS and Python teams who don't otherwise want to run a JVM FHIR server. Note bonfireDB is pre-launch with deliberately scoped (not full enterprise) FHIR conformance, while HAPI is mature and conformant today.

Does HAPI FHIR have built-in vector or semantic search for clinical notes?

No. As of 2026, HAPI's full-text search is keyword-only (Lucene/Elasticsearch _content/_text with a :contains substring modifier) and has no native embeddings or vector search — verify current capabilities before deciding. bonfireDB's design puts pgvector semantic search in the core, scoped by ABAC, but this is design-stage, not a shipped benchmarked feature.

Does HAPI FHIR include an agent or MCP layer for AI apps?

No. HAPI ships no MCP, LLM integration, or agent tooling — that layer is entirely yours to build. bonfireDB positions a build-your-own-MCP surface over clean typed projections as a first-class concern, though this is early-access positioning rather than a shipped product. HAPI also has no built-in authentication (its AuthorizationInterceptor handles authorization, not identity), so authn is DIY.