bonfireDB vs AWS HealthLake
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 hybrid search, and canonical FHIR R4 underneath.
TL;DR
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 hybrid search, and agent context tools — canonical FHIR R4 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.
At a glance
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; canonical FHIR R4, typed reads on top |
| Language / stack | Closed AWS service; internal storage/index engine not publicly documented | TypeScript + Postgres + pgvector |
| License / cost | Proprietary; ~$197/mo per always-on datastore (Advanced tier) + request costs | Planned Apache-2.0 core + managed tier (see pricing) |
| Hosting | Managed-only (AWS cloud); no self-host or local dev | Designed for your AWS or managed |
| App-native typed API | No — standard FHIR R4 REST, no typed clinical SDK | By design — typed clinical primitives |
| Fresh-on-commit app reads | Eventual for search — search indexing is asynchronous; consistency options aren’t publicly documented in detail (verify current AWS docs) | By design — committed operational read models |
| Reactive realtime cache | Server-push Subscriptions (Oct 2025); not a reactive cache | By design — useClinicalQuery |
| Built-in semantic search | None native — bolt on Bedrock/OpenSearch vectors yourself | By design — built in — hybrid (BM25 + vector), 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 over the FHIR API (11 tools, IAM-only authorization, one read-only flag, no per-caller capability contract); third-party guardrail proxies (e.g. HealthClaw) add step-up writes and human-in-the-loop over it — governance bolted onto a proxy rather than enforced in the data layer, and neither is benchmarked. In our FHIR-AgentBench fork, prompt-only agents over raw FHIR failed on context fit and evidence selection | Agent context tools over cited evidence packets |
| Clinical authorization (write-enforced) | SMART scopes + fixed GP-relationship rule; no custom write ABAC | By design — read + write enforced ABAC, auto-audit |
| Automatic audit / provenance | CloudTrail API logs; no auto FHIR AuditEvent/Provenance | Automatic by design |
| FHIR conformance / export | Mature FHIR R4 (no R4B/R5); US Core v7, Bulk Data v2, Da Vinci | Canonical FHIR R4 (JSONB), typed reads on top; 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) |
Where AWS HealthLake genuinely wins
- Zero ops, real maturity: GA since July 2021, a HIPAA-eligible always-on managed FHIR R4 server under the AWS BAA with an SLA, CloudTrail, and CloudFormation/CDK — no servers, scaling, patching, or backups to run.
- Strong regulatory + interoperability breadth: US Core up to STU v7 (USCDI v4), Bulk Data Access v2, SMART App Launch + OAuth2/OIDC, ONC Inferno-validated, plus CARIN BB and Da Vinci PDex/CDex/PAS — purpose-built for Cures Act / CMS mandates bonfire does not attempt.
- Deep AWS-native integration: IAM, CloudTrail, PrivateLink/VPC, EventBridge, Lake Formation governance, and zero-ETL SQL analytics over FHIR via Amazon Athena.
- Integrated Comprehend Medical NLP turns unstructured clinical text into queryable native FHIR resources (entities, relationships, PHI) without you building an NLP pipeline.
- Very active 2024-2026 roadmap closing historical FHIR gaps: Bundle transactions, JSON/FHIRPath Patch, $validate, SMART v2 scopes, FHIR Subscriptions (Oct 2025), async bundles, plus ETag/If-Match and idempotency-key concurrency control.
- Proven at scale: named enterprise users including Greenway Health (cited ~9.5B FHIR resources ingested), Rush, Cortica, InterSystems, and Redox — a track record an early-stage project cannot claim.
Where bonfireDB is built different
- Fresh-on-commit app reads: HealthLake search is eventually consistent by default, and its consistency options aren’t publicly documented in detail (verify current AWS docs). bonfire serves committed operational read models so app reads reflect the latest write without a per-call tax.
- Reactive realtime cache: HealthLake’s Oct-2025 FHIR Subscriptions are server-push notifications (REST-Hook / EventBridge), not a live reactive query layer or bidirectional sync — apps still poll or wire up their own cache. bonfire’s design is a reactive client query (useClinicalQuery) that updates as data changes.
- App-state-as-first-class: HealthLake is a FHIR system-of-record, so non-FHIR draft/app/UI state has no natural home and teams typically run a second database for it. bonfire is designed to hold app and clinical state in one typed store, with canonical FHIR R4 underneath.
- Write-enforced custom ABAC + Consent: HealthLake’s fine-grained authorization is a fixed rule (SMART user/ scopes plus a Patient.generalPractitioner / Patient.link relationship check) — not an arbitrary attribute-based policy engine, and it has no Consent-resource enforcement; broader per-tenant isolation you build in a proxy/Lambda yourself. bonfire’s design enforces ABAC on reads AND writes natively.
- Native semantic search: HealthLake has no built-in vector/semantic search — you bolt on Bedrock + OpenSearch vectors + Athena yourself. bonfire is designed to ship hybrid search (BM25 + vector) with the same ABAC enforcement applied to results.
- Agent / MCP layer over cited evidence packets: HealthLake has no in-service agent runtime; AWS Labs now ships an official open-source HealthLake MCP server (Jan 2026) as a self-hosted FHIR companion. That is still a raw-FHIR interface. bonfire’s agent context tools sit over cited, query-aware evidence packets instead, plus automatic audit on access.
- Cost + DX for a small team: HealthLake’s Advanced tier bills ~$0.27/hr (~$197/mo) per datastore, always on even at zero traffic, plus per-request charges — painful across dev/stage/prod and per-tenant stores — and is closed, AWS-only, with no self-host/local-dev/offline-CI option. bonfire’s core is planned as Apache-2.0, designed to run in your own AWS or a managed tier, and built to run locally.
Which should you choose?
Choose AWS HealthLake if…
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.
Choose bonfireDB if…
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 hybrid search, and an agent/MCP layer over cited evidence packets — with canonical FHIR R4 underneath rather than as the thing you build against — and you can accept an early-stage, largely-vision product over a mature managed service.
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
What is a good AWS HealthLake alternative for building an app?
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, canonical FHIR R4 underneath. If your job is exchange and conformance, HealthLake wins; if it’s shipping one app fast, bonfireDB is designed for that gap.
How much does AWS HealthLake cost?
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 planned as Apache-2.0, designed to run in your own AWS and locally.
Is AWS HealthLake HIPAA compliant?
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 designed as open-source software you run in your own AWS, so HIPAA compliance depends on how you deploy and operate it.
Does AWS HealthLake support semantic or vector search over clinical notes?
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 is designed to ship hybrid search (BM25 + vector) with ABAC enforcement applied to the results, so retrieval respects the same access policy as the rest of the data.
Are HealthLake reads consistent for an app, and is there a reactive cache?
HealthLake search indexing is asynchronous, so search results can lag writes; consistency options aren’t publicly documented in detail — verify current AWS docs. 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).