AWS HealthLake is a mature, HIPAA-eligible, fully managed FHIR R4 system-of-record with deep AWS integration and a strong Cures Act / payer-interop story. bonfireDB is an early-stage, app-native clinical backend (TypeScript + Postgres) that gives a single product team typed projections, fresh-on-commit reads, ABAC-enforced semantic search, and FHIR generated underneath.
If your job is to store, exchange, and analyze health data across systems — Cures Act / ONC / CMS conformance, payer IGs, Bulk Data export, SQL analytics over FHIR — HealthLake is a genuinely strong, battle-tested choice with zero ops and the full weight of AWS behind it. Where it's awkward is when one team is building an application on top of it: search is eventually consistent by default, there's no live reactive cache, fine-grained authz is a fixed SMART-scope relationship rule rather than a custom write-enforced ABAC engine, there's no native semantic/vector search and no in-service agent runtime (the official AWS Labs HealthLake MCP server, Jan 2026, is a self-hosted companion over raw FHIR), and the ~$197/mo-per-datastore always-on floor (Advanced tier, plus request costs) punishes dev/stage/prod and per-tenant designs. bonfire targets exactly that app-builder gap with typed clinical primitives, committed read models, a reactive query hook, built-in ABAC-enforced semantic search, and build-your-own-MCP — FHIR R4 generated underneath. bonfire is early-stage and largely positioning today; HealthLake is shipping, certified-adjacent, and running ~billions of FHIR resources in production at enterprise customers.
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.
| AWS HealthLake | bonfireDB | |
|---|---|---|
| Type | Managed FHIR R4 datastore (interop/analytics-first) | Agent-native clinical backend; FHIR generated underneath |
| Language / stack | Closed AWS service; DynamoDB + OpenSearch internally | TypeScript + Postgres + pgvector |
| License / cost | Proprietary; ~$197/mo per always-on datastore (Advanced tier) + request costs | Apache-2.0 core (free) + managed tier (see pricing) |
| Hosting | Managed-only (AWS cloud); no self-host or local dev | Your AWS (OSS) or managed |
| App-native typed API | No — standard FHIR R4 REST, no typed clinical SDK | Yes — typed clinical primitives |
| Fresh-on-commit app reads | Eventual by default; strong is opt-in, doubles write cost | Yes — committed operational read models |
| Reactive realtime cache | Server-push Subscriptions (Oct 2025); not a reactive cache | Yes — useClinicalQuery |
| Built-in semantic search | None native — bolt on Bedrock/OpenSearch vectors yourself | Built in — pgvector, ABAC-enforced |
| Agent / MCP layer | No in-service agent runtime; the official AWS Labs OSS HealthLake MCP server (Jan 2026) is a self-hosted companion (11 FHIR tools, read-only mode), and agents over raw FHIR still cap ~50% (FHIR-AgentBench) | Build-your-own-MCP over clean projections |
| Clinical authorization (write-enforced) | SMART scopes + fixed GP-relationship rule; no custom write ABAC | Read + write enforced ABAC, auto-audit |
| Automatic audit / provenance | CloudTrail API logs; no auto FHIR AuditEvent/Provenance | Automatic |
| FHIR conformance / export | Mature FHIR R4 (no R4B/R5); US Core v7, Bulk Data v2, Da Vinci | FHIR R4 generated underneath; scoped conformance (honest: not a full enterprise FHIR server) |
| Best for | Enterprise interoperability, payer exchange, analytics at scale | Builders of AI-native health apps (scribes, copilots, agents) |
Your primary job is interoperability, regulatory conformance, payer data exchange, or analytics at enterprise scale — Cures Act / ONC / CMS, Bulk Data export, US Core, Da Vinci IGs, SQL over FHIR — and you want a fully managed, certified-adjacent, battle-tested FHIR system-of-record with zero ops and deep AWS integration.
You're a small team shipping an outpatient or AI-native healthcare app and you want typed primitives, fresh-on-commit reactive reads, built-in ABAC-enforced semantic search, and an agent/MCP layer over clean projections — with FHIR generated underneath rather than as the thing you build against — and you can accept an early-stage, largely-vision product over a mature managed service.
Open source. Runs in your AWS. The clinical layer is handled.
HealthLake is a strong managed FHIR R4 datastore for interop and analytics, but it's interop-first, not app-first. bonfireDB is an early-access, app-native TypeScript + Postgres clinical backend with typed primitives, fresh-on-commit reads, and built-in ABAC, FHIR generated underneath. If your job is exchange and conformance, HealthLake wins; if it's shipping one app fast, bonfireDB is designed for that gap.
As of 2026 (verify current pricing), HealthLake's Advanced tier bills roughly $0.27/hr (~$197/mo) per datastore, always on even at zero traffic, plus per-request charges. That floor multiplies across dev, stage, prod, and per-tenant stores. bonfireDB's core is Apache-2.0, runs in your own AWS, and is built to run locally.
Yes. As of 2026, HealthLake is a HIPAA-eligible AWS service available under the AWS BAA, with CloudTrail logging and an SLA. Verify current eligibility and sign a BAA for your account. bonfireDB is open-source software you run in your own AWS, so HIPAA compliance depends on how you deploy and operate it.
Not natively, as of 2026. HealthLake has no built-in vector/semantic search, so you bolt on Bedrock plus OpenSearch vectors and Athena yourself. bonfireDB ships pgvector semantic search with ABAC enforcement applied to the results, so retrieval respects the same access policy as the rest of the data.
HealthLake search is eventually consistent by default; strong consistency is opt-in per request, doubles write-capacity cost, and only works on history-enabled stores. Its Oct-2025 FHIR Subscriptions are server-push notifications, not a reactive query layer. bonfireDB is designed for committed read models and a reactive client hook (useClinicalQuery).