An honest, side-by-side comparison of clinical backends on the axis that matters for AI-native health apps: can an agent read — and safely aggregate — the record? Plus the table-stakes for app builders. We map each option across the dimensions that decide whether you ship in a weekend or assemble a clinical platform for months — typed app primitives, fresh reads, reactive caching, semantic search, agent layers, write-enforced authorization, audit, and FHIR conformance.
New to this? Start with why build on FHIR and FHIR explained for app developers.
Pick up to three alternatives to put head-to-head with bonfireDB — it’s always in the final column. Each cell reflects bonfireDB’s design and positioning, not shipped traction. Vendor pricing and capabilities change; treat figures as a point-in-time snapshot and verify current pricing/capabilities (2026) before deciding.
| Medplum | AWS HealthLake | HAPI FHIR | Aidbox | Firely Server | Smile CDR | Google Healthcare API | Azure Health Data | Plain Postgres | Supabase / Convex | bonfireDB | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Type | Open-source FHIR-native developer platform ("headless EHR") | Managed FHIR R4 datastore (interop/analytics-first) | Open-source FHIR server + toolkit (data store, not an app framework) | Commercial production-grade FHIR server + data platform | Commercial, certified turn-key native FHIR server (formerly Vonk) | Enterprise FHIR clinical data repository / health-data fabric | Managed FHIR/HL7v2/DICOM data plane (not an app) | Managed enterprise FHIR R4 server (PaaS); MIT OSS engine to self-host | General-purpose relational DB — not a healthcare/FHIR product | General-purpose app backend (BaaS); not healthcare- or FHIR-aware | Agent-native clinical backend; FHIR generated underneath |
| Language / stack | TypeScript end-to-end; Node + Postgres + Redis | Closed managed AWS service; internal storage/index engine not publicly documented | Java / JPA-Hibernate, Spring Boot, Lucene or Elasticsearch | Clojure/JVM core; PostgreSQL JSONB storage | .NET / C# on Firely .NET SDK; SQLite / SQL Server / MongoDB | Java / JVM on HAPI FHIR; Linux-only; Postgres/Oracle/MSSQL + ES + Kafka | Closed-source Google-managed; REST/gRPC + client libs | Managed PaaS over microsoft/fhir-server (C#/.NET, Azure SQL or Cosmos DB) | PostgreSQL (C) + pgvector; app tier in any language | Supabase: Postgres + PostgREST/GoTrue/Realtime. Convex: Rust + TypeScript reactive backend | TypeScript + Postgres + pgvector |
| License / cost | Apache-2.0 core (free self-host); managed cloud is paid — see vendor pricing | Proprietary; ~$197/mo per datastore always-on (Advanced tier) + request costs | Apache-2.0, $0 license; you run infra/ops, or pay Smile CDR | Proprietary; Dev free (no PHI), Base from ~$19K/yr (verify current pricing, 2026) | Closed-source; flat-fee annual license, contact-sales (no public pricing) | Commercial, closed-source, contact-sales; per-module premium license keys | Proprietary pay-as-you-go; free tier, no license fee — see vendor pricing | Managed: proprietary, consumption-priced (free request tier); OSS engine MIT — see vendor pricing | Free (PostgreSQL + pgvector BSD-style); pay infra + engineering | Supabase core Apache-2.0; Convex core FSL-1.1 (auto-converts to Apache-2.0 two years after each release), not Apache-2.0 today. HIPAA/BAA paid: Supabase Team + HIPAA add-on; Convex BAA from a paid tier — see vendor pricing | Apache-2.0 core (free) + managed tier |
| Hosting | Managed cloud or self-host on your AWS (~0.5 FTE ops) | Managed-only (AWS cloud); no self-host or local dev | Self-host (Docker/Tomcat) by default; managed only via commercial Smile CDR | Both — self-hosted (Docker/K8s) or managed cloud | Self-hosted only (anywhere); no production managed SaaS | Self-host (Docker/K8s, Linux) or managed; no free sandbox | Google-managed only; no self-host or VPC | Managed in Azure (no DB access) or self-host OSS in your subscription; Azure-only | Self-managed or managed (RDS/Aurora/Cloud SQL/Azure), HIPAA-eligible under BAA | Both managed (primary) or self-host; HIPAA controls only on hosted + BAA | Your AWS (OSS) or managed |
| App-native typed API | FHIR-native + generated types; no custom resource types (use Basic/extensions) | No — standard FHIR R4 REST, no typed clinical SDK | No — FHIR data store; build your typed app layer yourself | FHIR-first; custom resources, but not typed app primitives | No — FHIR server, not an app platform; BYO app/business logic | No — FHIR REST surface; custom logic via Java interceptors | No — raw FHIR resources, no typed app primitives | No — you code against the FHIR REST API; no custom resource types | No — JSONB + SQL; you build every clinical primitive | Yes (generic): Supabase auto REST/GraphQL; Convex end-to-end typed TS — no clinical model | Yes — typed clinical primitives |
| Fresh-on-commit app reads | Yes — strongly consistent; writes immediately searchable | Eventual by default; strong is opt-in, doubles write cost | Yes for structured search (ACID relational); full-text index is async unless forced | Yes — Postgres ACID gives strong read-after-write | FHIR-search-backed; no guaranteed read-your-write app contract | Parameter search is transactional; full-text (ES) is async by default | No — search indexed async; only identifier synchronous | Writes strongly consistent; search index decoupled, lenient, needs reindex for custom params | Yes — native ACID/MVCC strong read-after-write consistency | Yes — Postgres MVCC / Convex OCC; strongly consistent (but no clinical read model) | Yes — committed operational read models |
| Reactive realtime cache | Subscriptions + useSubscription hook; no auto-reactive query cache | Server-push Subscriptions (Oct 2025); not a reactive cache | Subscriptions (REST-hook/WebSocket/topic), but no app-native reactive cache hook | Server-push subscriptions + $watch API; no frontend live-query cache | Dated: STU3/R4 rest-hook subscriptions only; no WebSocket push | Server-side FHIR Subscriptions (Kafka/WebSocket); no client reactive cache | No — Pub/Sub change events, not client push | No native Subscription; Event Grid only, unordered, at-least-once, bulk lag up to days | Primitives only (LISTEN/NOTIFY, logical decoding); no reactive layer | Yes — Convex live queries; Supabase Postgres-Changes/Broadcast/Presence (single-thread WAL limits) | Yes — useClinicalQuery |
| Built-in semantic search | No built-in vector/semantic search; DIY on Postgres | None native — bolt on Bedrock/OpenSearch vectors yourself | No native vector/embeddings; full-text keyword only (_content/_text :contains) | None built in — you add pgvector/embeddings yourself | None — no vector/embeddings/RAG (verified) | No native vector/semantic search; parameter + full-text only | Yes — Agent Search for healthcare ships FHIR-native semantic search today, but sunsets 2027-05-15 | None in-store; no _text/_content; $export to Fabric/Azure AI for embeddings | pgvector primitive only; pipeline + result authz are DIY | Generic only — pgvector (Supabase) / native vector search + RAG (Convex); not PHI/ABAC-aware | Built in — pgvector, ABAC-enforced |
| Agent / MCP layer | MCP server shipped (June 2025); at launch flagged experimental + PHI-prohibited — docs have since softened, re-verify | Official AWS Labs OSS HealthLake MCP server (Jan 2026): 11 FHIR tools (CRUD, search, $patient-everything, import/export), read-only mode — self-hosted companion, not an in-service runtime; raw-FHIR agents still cap ~50% (FHIR-AgentBench) | None native — no MCP or LLM/agent layer; entirely DIY | No native MCP/agent layer; SQL-on-FHIR/GraphQL building blocks only | None built in; raw-FHIR agents cap ~50% (FHIR-AgentBench) | No product MCP or agent layer; build over raw FHIR REST | None built in — roll your own over FHIR | None built in; build your own RAG/agent downstream after $export | None — no MCP/agent layer; you build it all | Generic AI/RAG/agent components; build your own — no clinical/consent-aware retrieval | Build-your-own-MCP over clean projections |
| Clinical authorization (write-enforced) | Yes — Access Policies, ABAC criteria, compartments, write constraints | SMART scopes + fixed GP-relationship rule; no custom write ABAC | Yes — AuthorizationInterceptor enforces request and response; no built-in authentication | Strong — AccessPolicy RBAC/ABAC + element-level Security Labels | OAuth2 resource server; SMART scopes + compartments, BYO IdP | Mature SMART/OAuth2 + compartment & partition permissions (write-enforced) | IAM (store-level) + read-only Consent; writes not enforced | Coarse service-level Entra RBAC; patient-scoped needs SMART Enhanced sample + APIM | RLS + roles only; clinical ABAC/SMART/consent are your code | No clinical authz: Supabase RLS hand-written SQL; Convex has no RLS, all checks in code | Read + write enforced ABAC, auto-audit |
| Automatic audit / provenance | Full FHIR AuditEvents, but REST capture needs logAuditEvents enabled | CloudTrail API logs; no auto FHIR AuditEvent/Provenance | Optional automatic AuditEvents via BALP interceptor once registered | Automatic BALP AuditEvents (opt-in setting; $import/GraphQL gaps) | Tamper-resistant BALP AuditEvents, but plugin-enabled + paid Scale tier | Automatic — all actions audited to admin-schema audit DB by default | Cloud Audit Logs (platform), not auto FHIR AuditEvents | No FHIR AuditEvent written; Azure Monitor AuditLogs (caller, IP, URI) you route yourself | WAL/triggers only; FHIR AuditEvent/Provenance hand-built | No clinical audit — generic DB logging only; no AuditEvent/Provenance | Automatic |
| FHIR conformance / export | FHIR R4 native, US Core, ONC (g)(10) certified; $everything/Bulk export | Mature FHIR R4 (no R4B/R5); US Core v7, Bulk Data v2, Da Vinci | Native FHIR-first: DSTU2-R5, full REST, $export; certs only via commercial Smile CDR | Broad — STU3–R6, 500+ IGs, ONC (g)(10) certified, Bulk export | Best-in-class: native STU3/R4/R5, ONC g(10), US Core, SMART certified | Full DSTU2-R5, ONC (g)(10) + Drummond certified, Bulk Data $export | Mature DSTU2/STU3/R4; validation, history, Bulk $export | Strong, spec-faithful R4 (+STU3); transaction bundles, chained search, $export; no R4B/R5/terminology | None out of the box; full FHIR API, search, export, g10 from scratch | None — no FHIR model, endpoints, validation, $-ops, _history, or bulk export | FHIR R4 generated underneath; scoped conformance (honest: not a full enterprise FHIR server) |
| Best for | Teams wanting a mature, certified FHIR platform to build on | Enterprise interoperability, payer exchange, analytics at scale | Teams needing proven, broad FHIR conformance with Java/DevOps capacity | Teams needing certified, broad, scalable FHIR today | Enterprises/regulated orgs needing certified, validation-grade FHIR | Payers, providers, government interoperability programs at scale | Enterprise interop, data harmonization, analytics pipelines | Managed interoperability, ingestion, and data platforms at enterprise/Epic scale | Teams/vendors with depth and time to build + certify the clinical layer themselves | Small teams shipping a general app fast and willing to build the entire healthcare layer themselves | Builders of AI-native health apps (scribes, copilots, agents) |
Read the full, honest breakdown for any alternative.
Medplum is the mature, ONC-certified FHIR-native backend you build a clinical app on; bonfireDB is an earlier-stage, app-first clinical layer that generates FHIR underneath instead of asking you to model everything as FHIR.
Compare →A managed FHIR R4 datastore built for enterprise interoperability and analytics, compared with a TypeScript clinical backend designed for one team building an app fast.
Compare →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.
Compare →Aidbox is a mature, certified, proprietary FHIR-on-Postgres platform you license; bonfire is an early-stage, open-source, app-and-agent-native clinical backend that generates FHIR underneath.
Compare →Firely Server (Vonk) is the certified, conformance-first FHIR data layer you buy to prove interoperability; bonfire is the OSS clinical app backend you build on when one team needs fresh reads, ABAC, and AI over their own data.
Compare →Smile CDR is the enterprise FHIR data fabric for payers, providers, and government interoperability programs; bonfireDB is an early-stage app-building backend for teams shipping outpatient and AI healthcare products fast.
Compare →Google Cloud Healthcare API is a mature, fully-managed FHIR/HL7v2/DICOM data plane for enterprise interoperability and analytics; bonfireDB is an early-stage app-native clinical backend that generates FHIR underneath so a small team can ship an outpatient or AI healthcare product fast.
Compare →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.
Compare →Plain PostgreSQL is the maximum-control, maximum-work foundation — a world-class database with zero healthcare functionality — while bonfire is an opinionated clinical backend built on that same Postgres so you don't hand-build the FHIR, authz, audit, and agent layers yourself.
Compare →Supabase and Convex are excellent general-purpose backends — but they hand you a database and realtime plumbing, not a healthcare data layer; with them you build the FHIR server, the terminology, and the clinical access control yourself, whereas bonfire ships those as the product.
Compare →Open source. Runs in your AWS. The clinical layer is handled.
It depends on your goal. Mature FHIR servers fit teams that need broad conformance and have ops capacity — Medplum and Aidbox are ONC (g)(10) certified, while HAPI FHIR is a free open-source engine you certify yourself. bonfireDB is designed for founders shipping outpatient or AI apps fast: typed clinical primitives, fresh reads, and ABAC-enforced search, with FHIR R4 generated underneath rather than modeled by hand. It's early access and pre-launch.
HealthLake is a managed FHIR R4 datastore built for enterprise interoperability and analytics, priced around $197/mo per always-on datastore plus request costs, managed-only, with eventual-consistency search by default. If you're a small team building an app rather than an interop pipeline, an app-native backend like bonfireDB, Medplum, or Aidbox is usually a closer fit. bonfireDB is designed to run in your own AWS (OSS) or managed, with committed operational read models.
Plain Postgres gives you maximum control and zero healthcare functionality — you build the FHIR API, terminology, authorization, audit, and export from scratch. A FHIR server or clinical backend ships those for you. bonfireDB is built on Postgres + pgvector and is designed to add typed clinical primitives, write-enforced ABAC, automatic audit, and generated FHIR R4, so you don't hand-build the clinical layer.
Supabase and Convex are excellent general backends, but neither is healthcare- or FHIR-aware. You'd build the FHIR model, terminology, clinical access control, and audit yourself, and HIPAA controls require their paid hosted tiers with a BAA. bonfireDB is designed as the clinical data layer above that gap, shipping FHIR generation, ABAC, audit, and clinical primitives as the product.
As of 2026, most FHIR servers (HAPI, Aidbox, Firely, Smile CDR, Azure) have no native vector search and leave embeddings DIY. Google's Agent Search for healthcare offers FHIR-native semantic search today but is slated to sunset 2027-05-15 (verify current). bonfireDB is designed with built-in pgvector semantic search that's ABAC-enforced, plus build-your-own-MCP over clean projections so agents work over consent-aware data. Verify each vendor's current capabilities before deciding.