bonfireDB vs Azure Health Data Services

TL;DR

Azure Health Data Services is a genuinely managed, GA, enterprise-grade FHIR R4 server: Microsoft owns ops, scaling, patching, and the compliance posture, it implements transaction bundles, chained/reverse-chained search, $patient-everything and $export faithfully, and it has real Epic-on-Azure production scale behind it. Its trade-offs are for an interoperability/data-platform role, not a single app team: native authorization is coarse service-level Entra RBAC (patient-scoped SMART access requires deploying a separate sample plus APIM), it writes no FHIR AuditEvent resources into the store, has no terminology operations, no in-store semantic/vector or agent layer, and its eventing is unordered, at-least-once, and can lag for days under bulk load. bonfireDB targets exactly that app-builder shape — typed projections, committed read models, a reactive cache, built-in ABAC-enforced semantic search, build-your-own-MCP, and automatic audit — but it is early-stage and largely a design/positioning bet, not a shipped enterprise FHIR server. Choose Azure for proven managed interoperability at scale; consider bonfire if you're a founder building an outpatient or AI healthcare app and want app-native ergonomics with FHIR generated underneath.

At a glance

Azure Health Data Services is a mature, fully-managed enterprise FHIR server for interoperability and data platforms; bonfireDB is an early-stage, app-native clinical backend that generates FHIR underneath so a single product team can ship fast.

	Azure Health Data Services	bonfireDB
Type	Managed enterprise FHIR R4 server (PaaS); MIT OSS engine to self-host	Agent-native clinical backend; FHIR generated underneath
Language / stack	Managed PaaS over microsoft/fhir-server (C#/.NET, Azure SQL or Cosmos DB)	TypeScript + Postgres + pgvector
License / cost	Managed: proprietary, consumption-priced (free request tier); OSS engine MIT	Apache-2.0 core (free) + managed tier
Hosting	Managed in Azure (no DB access) or self-host OSS in your subscription; Azure-only	Your AWS (OSS) or managed
App-native typed API	No — you code against the FHIR REST API; no custom resource types	Yes — typed clinical primitives
Fresh-on-commit app reads	Partial — writes strongly consistent; search index decoupled, lenient, needs reindex for custom params	Yes — committed operational read models
Reactive realtime cache	No native Subscription; Event Grid only, unordered, at-least-once, bulk lag up to days	Yes — useClinicalQuery
Built-in semantic search	None in-store; no _text/_content; $export to Fabric/Azure AI for embeddings	Built in — pgvector, ABAC-enforced
Agent / MCP layer	None built in; build your own RAG/agent downstream after $export	Build-your-own-MCP over clean projections
Clinical authorization (write-enforced)	Coarse service-level Entra RBAC; patient-scoped needs SMART Enhanced sample + APIM	Read + write enforced ABAC, auto-audit
Automatic audit / provenance	No FHIR AuditEvent written; Azure Monitor AuditLogs (caller, IP, URI) you route yourself	Automatic
FHIR conformance / export	Strong, spec-faithful R4 (+STU3); transaction bundles, chained search, $export; no R4B/R5/terminology	FHIR R4 generated underneath; scoped conformance (honest: not a full enterprise FHIR server)
Best for	Managed interoperability, ingestion, and data platforms at enterprise/Epic scale	Builders of AI-native health apps (scribes, copilots, agents)

Where Azure Health Data Services genuinely wins

Truly managed and GA: Microsoft owns FHIR-server operations, patching, autoscaling (on by default at no extra charge), and the platform compliance posture — HIPAA/HITECH BAA available by default via Product Terms, plus HITRUST CSF, ISO 27001, and SOC 1/2/3.
Spec-faithful FHIR R4 REST implementation: batch and transaction bundles, chained and reverse-chained (_has) search, _include/_revinclude, $patient-everything, $export, $import, and $convert-data all supported, with a standard CapabilityStatement at /metadata.
Strongly consistent writes through the API and enterprise business continuity: point-in-time recovery and availability-zone support, provisioned in minutes with consumption pricing and a free request tier.
Tight Azure ecosystem: Microsoft Entra ID identity (plus any OIDC IdP), Event Grid eventing, Azure Monitor diagnostic logging, and a clean $export path into Microsoft Fabric / Synapse / Databricks for downstream analytics and AI.
Backed by an MIT-licensed open-source engine (microsoft/fhir-server, ~380 releases, daily test builds) you can read or self-host — a real transparency and escape-hatch advantage.
Proven enterprise and Epic credibility at scale (e.g. large Epic-on-Azure production deployments), which de-risks the choice for buyers who weight references and longevity.

Where bonfireDB is built different

App-native typed clinical primitives vs FHIR-as-the-API: Azure's managed service exposes only the FHIR REST surface (no DB access, no custom resource types — you extend Basic with extensions), so an app team codes against interoperability-shaped JSON. bonfire's design targets clean typed projections with FHIR generated underneath. (Verified: managed AHDS has no underlying-data access and no custom resources.)
Fresh-on-commit application reads: Azure writes are strongly consistent, but its search index and eventing are decoupled, lenient by default (unknown/typo'd params are silently ignored), and custom search params require a reindex job before they work. bonfire's design is committed operational read models you can read immediately after write. (Verified: lenient default + reindex requirement in Azure search docs.)
Built-in reactive realtime cache: Azure has no native FHIR Subscription resource in the managed service — reactivity is wired through Event Grid (create/update/soft-delete only), events are explicitly NOT ordered, delivery is at-least-once (duplicates), and under bulk load delivery lag 'can extend to multiple days.' bonfire's design is a reactive query hook over committed state. (Verified: Events FAQ.)
Built-in ABAC-enforced semantic search: Azure has no in-store vector/semantic search and no full-text (_text/_content are unsupported) — the blessed pattern is $export to a downstream AI layer. bonfire's design embeds pgvector semantic search with access control enforced at the hit level. (Verified: search param table + Microsoft's export-to-Fabric guidance.)
Automatic, queryable audit: Azure does NOT write FHIR AuditEvent resources into the store; audit comes only as Azure Monitor 'AuditLogs' diagnostic logs (caller identity, IP, request URI, operation) you route to Log Analytics/Storage/Event Hub yourself. bonfire's design auto-records provenance in-model. (Verified: FHIR service diagnostic-logs reference.)
Clinical authorization built in (read AND write enforced): Azure's native access control is coarse service-level Entra RBAC (e.g. FHIR Data Reader/Writer) — not per-patient or per-compartment; granular SMART/patient-scoped access requires deploying the separate 'SMART on FHIR (Enhanced)' sample plus APIM/Functions, which the docs note 'need to be integrated.' bonfire's design enforces ABAC in-engine. (Verified: SMART-on-FHIR docs.)

Which should you choose?

Choose Azure Health Data Services if…

Choose Azure Health Data Services if you need a proven, fully-managed, compliance-certified FHIR R4 server for interoperability, ingestion, or a data platform — especially in the Microsoft/Epic ecosystem with $export to Fabric/Databricks — and you want Microsoft to own ops and the compliance posture at enterprise scale.

Choose bonfireDB if…

Consider bonfireDB if you're a founder or small team building an outpatient or AI-native healthcare application and want app-native ergonomics — typed projections, fresh-on-commit reads, a reactive cache, ABAC-enforced semantic search, build-your-own-MCP, and automatic audit — with FHIR generated underneath, accepting that bonfire is early-stage and not a full enterprise FHIR server.

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

FAQ

Frequently asked questions

What is a good Azure Health Data Services alternative for building an app?

Azure Health Data Services is a managed enterprise FHIR R4 server built for interoperability and data platforms, where you code against the FHIR REST API. bonfireDB takes the opposite shape: an app-native clinical backend (TypeScript + Postgres) with typed clinical primitives and FHIR generated underneath. bonfireDB is early access and not a full enterprise FHIR server, so choose Azure for proven managed interoperability at scale.

Azure FHIR vs an app backend — which should I use?

Use Azure's FHIR service when you need a GA, compliance-certified FHIR R4 endpoint that Microsoft operates for interoperability, ingestion, or $export into Fabric/Databricks. Consider an app backend like bonfireDB when you're building a single outpatient or AI healthcare app and want typed projections, fresh-on-commit reads, a reactive cache, and built-in audit instead of coding against interoperability-shaped JSON.

Does Azure Health Data Services have built-in semantic or vector search?

As of 2026 (verify current), the managed service has no in-store vector or semantic search and no full-text _text/_content; the documented pattern is $export to a downstream Azure AI layer. bonfireDB is designed to embed pgvector semantic search directly, with ABAC access control enforced at the individual hit level.

Does Azure FHIR service write FHIR AuditEvent resources?

No. As of 2026 (verify current), Azure does not write FHIR AuditEvent resources into the store; audit comes only as Azure Monitor diagnostic AuditLogs (caller, IP, request URI) that you route to Log Analytics or storage yourself. bonfireDB is designed to auto-record provenance in-model so audit is queryable by default.

How granular is authorization in Azure Health Data Services?

Native access control is coarse, service-level Entra RBAC (e.g. FHIR Data Reader/Writer), not per-patient or per-compartment. As of 2026 (verify current), patient-scoped SMART access requires deploying the separate SMART on FHIR (Enhanced) sample plus APIM. bonfireDB is designed to enforce ABAC in-engine on both reads and writes.