Cloud Healthcare API gives you a rock-solid, serverless FHIR store under a Google HIPAA BAA — but it's persistence-plus-eventing, not an application: you still build the app, the per-patient authorization, the realtime layer, and — once Google's FHIR-native semantic-search product sunsets (EOL 2027-05-15) — your own agent stack. bonfire is designed for the opposite starting point — typed clinical primitives, fresh-on-commit reads, and ABAC-enforced semantic search with FHIR emitted underneath.
Google Cloud Healthcare API is a genuinely mature, GA managed service — multi-modal FHIR/HL7v2/DICOM, profile validation on write, de-identification, BigQuery/Pub-Sub integration, a native (read-side) Consent engine, and named enterprise users like Mayo and Hackensack Meridian — and for interoperability, research data harmonization, and analytics it is a strong, low-ops foundation. But it is a data plane, not an app: a small team still builds the UI, domain logic, per-patient/per-tenant authorization, and the entire realtime fan-out, and FHIR search is eventually consistent with no strong-read option. bonfireDB is early-stage and largely vision, so its column reflects design intent, not a shipped, certified product. Where the two genuinely diverge is app-builder ergonomics: fresh-on-commit operational reads, a reactive client cache, write-enforced ABAC with auto-written audit, build-your-own-MCP over clean projections, and built-in ABAC-enforced semantic search — areas where Google's offering is eventually consistent, read-only-consent, log-based-audit, and (for semantic search) shipping today but sunsetting in 2027.
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.
| Google Cloud Healthcare API | bonfireDB | |
|---|---|---|
| Type | Managed FHIR/HL7v2/DICOM data plane (not an app) | Agent-native clinical backend; FHIR generated underneath |
| Language / stack | Closed-source Google-managed; REST/gRPC + client libs | TypeScript + Postgres + pgvector |
| License / cost | Proprietary pay-as-you-go; free tier, no license fee | Apache-2.0 core (free) + managed tier |
| Hosting | Google-managed only; no self-host or VPC | Your AWS (OSS) or managed |
| App-native typed API | No — raw FHIR resources, no typed app primitives | Yes — typed clinical primitives |
| Fresh-on-commit app reads | No — search indexed async; only identifier synchronous | Yes — committed operational read models |
| Reactive realtime cache | No — Pub/Sub change events, not client push | Yes — useClinicalQuery |
| Built-in semantic search | Ships today — Agent Search for healthcare is FHIR-native, but sunsets 2027-05-15 | Built in — pgvector, ABAC-enforced |
| Agent / MCP layer | None built in — roll your own over FHIR | Build-your-own-MCP over clean projections |
| Clinical authorization (write-enforced) | IAM (store-level) + read-only Consent; writes not enforced | Read + write enforced ABAC, auto-audit |
| Automatic audit / provenance | Cloud Audit Logs (platform), not auto FHIR AuditEvents | Automatic |
| FHIR conformance / export | Mature DSTU2/STU3/R4; validation, history, Bulk $export | FHIR R4 generated underneath; scoped conformance (honest: not a full enterprise FHIR server) |
| Best for | Enterprise interop, data harmonization, analytics pipelines | Builders of AI-native health apps (scribes, copilots, agents) |
Choose Google Cloud Healthcare API if you need a battle-tested, fully-managed, multi-modal (FHIR + HL7v2 + DICOM) store under a Google HIPAA BAA — especially for interoperability, data harmonization, de-identification, and BigQuery/Vertex analytics at enterprise scale — and you have the engineering to build the application, authorization, realtime, and agent layers on top.
Choose bonfire if you're a small team shipping an outpatient or AI healthcare app and want app-native typed primitives, fresh-on-commit reads, write-enforced ABAC with automatic audit, and built-in semantic search — accepting that bonfire is early-stage with scoped (not full enterprise) FHIR conformance, and that you'll still emit standards-conformant FHIR R4 underneath.
Open source. Runs in your AWS. The clinical layer is handled.
Google Cloud Healthcare API is a mature managed FHIR/HL7v2/DICOM data plane, but it's persistence, not an application. bonfireDB is designed as the app backend that generates FHIR underneath (not a FHIR server): typed clinical primitives, fresh-on-commit reads, and write-enforced ABAC, with FHIR R4 generated underneath. It's early access, so it fits if you want app-builder ergonomics over a full enterprise interop store.
Google's docs carry an explicit notice that the currently-shipping FHIR-native search (Agent Search for healthcare) won't be available after May 15, 2027 (verify current status with Google). bonfireDB is designed to build semantic search in directly via pgvector, with ABAC applied per hit at query time.
No. Per Google's docs, FHIR resources are indexed asynchronously, so writes don't immediately appear in search results; only search-by-identifier is synchronous, and there's no caller-selectable strong-read option. bonfireDB is designed around committed operational read models so create-then-list flows are immediately consistent.
Per Google's docs, IAM stops at the store level and its FHIR Consent enforcement is read-only — write methods aren't supported by consent enforcement. bonfireDB's design enforces ABAC on both reads and writes, with audit written automatically. Verify Google's current consent capabilities before deciding.
No — as of 2026 it's Google-managed only, with no self-host or VPC option (verify current). bonfireDB's Apache-2.0 core is designed to run in your own AWS, with an optional managed tier. It's early access today.