Supabase (Postgres + PostgREST + Realtime + Auth) and Convex (reactive TypeScript backend) are two of the best ways to ship an app fast, and both can legally hold PHI under a BAA. Neither knows anything about FHIR, clinical terminology, consent, or resource-level audit — that entire healthcare-domain layer is yours to build.
Supabase and Convex are mature, well-funded, genuinely delightful general-purpose backends: Supabase gives you raw Postgres with instant REST/GraphQL/realtime/auth/storage and pgvector; Convex gives you end-to-end-typed TypeScript with automatic, transactionally-consistent reactive queries. Both are HIPAA-eligible with a signed BAA and SOC 2 Type 2, so they are a perfectly valid substrate to store PHI. What they are not is healthcare-aware: there is no FHIR resource model, no /fhir/R4 endpoints, no terminology (SNOMED/LOINC/ICD/RxNorm), no consent engine, and no resource-level clinical audit — and clinical authorization is hand-built (intricate Supabase RLS, or all-in-code checks on Convex, which has no row-level security at all). bonfire is early-stage and largely vision today, but it is positioned to give you typed clinical primitives, fresh-on-commit reads, an ABAC-enforced semantic layer, automatic audit, and FHIR R4 generated underneath — so you own the app, not the healthcare plumbing.
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.
| Supabase / Convex (general backend) | bonfireDB | |
|---|---|---|
| Type | General-purpose app backend (BaaS); not healthcare- or FHIR-aware | Agent-native clinical backend; FHIR generated underneath |
| Language / stack | Supabase: Postgres + PostgREST/GoTrue/Realtime. Convex: Rust + TypeScript reactive backend | TypeScript + Postgres + pgvector |
| License / cost | Supabase Apache-2.0, HIPAA needs a paid Team plan + HIPAA add-on; Convex FSL→Apache-2.0, BAA on a paid tier (verify current pricing, 2026) | Apache-2.0 core (free) + managed tier |
| Hosting | Both managed (primary) or self-host; HIPAA controls only on hosted + BAA | Your AWS (OSS) or managed |
| App-native typed API | 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 — Postgres MVCC / Convex OCC; strongly consistent (but no clinical read model) | Yes — committed operational read models |
| Reactive realtime cache | Yes — Convex live queries; Supabase Postgres-Changes/Broadcast/Presence (single-thread WAL limits) | Yes — useClinicalQuery |
| Built-in semantic search | Generic only — pgvector (Supabase) / native vector search + RAG (Convex); not PHI/ABAC-aware | Built in — pgvector, ABAC-enforced |
| Agent / MCP layer | Generic AI/RAG/agent components; build your own — no clinical/consent-aware retrieval | Build-your-own-MCP over clean projections |
| Clinical authorization (write-enforced) | 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 | No clinical audit — generic DB logging only; no AuditEvent/Provenance | Automatic |
| FHIR conformance / export | 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 | 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) |
Choose Supabase or Convex if you want the most mature, best-DX general-purpose backend to ship fast and you are comfortable owning the entire healthcare-domain layer yourself — or if your app is only lightly clinical and a HIPAA-eligible Postgres/reactive store under a BAA is genuinely all you need.
Choose bonfire if you are a small team building an outpatient or AI healthcare app and don't want to spend months reimplementing a FHIR server, terminology, consent-enforced authz, and clinical audit on top of a generic backend — you want typed clinical primitives, fresh reads, ABAC-enforced semantic search, and FHIR generated underneath, accepting that bonfire is early-stage today.
Open source. Runs in your AWS. The clinical layer is handled.
As of 2026, Supabase is HIPAA-eligible with a signed BAA and SOC 2 Type 2 on its paid Team plan plus the HIPAA add-on, so it can legally store PHI. But HIPAA-eligible storage is not the same as a clinical backend: it has no FHIR model, terminology, consent engine, or resource-level audit. Verify current pricing and terms.
As of 2026, Convex offers a BAA on a paid tier and is SOC 2 Type 2, so it can hold PHI. Note that Convex has no row-level security at all, so every clinical access check lives in your code, by hand. Verify current capabilities before deciding.
You can store PHI on either under a BAA, but neither is healthcare-aware: no FHIR R4, no SNOMED/LOINC/ICD/RxNorm, no consent or write-enforced clinical authorization, and no AuditEvent/Provenance. That entire healthcare-domain layer is yours to build. bonfireDB is designed to ship those clinical primitives as the product.
Supabase and Convex are excellent general-purpose backends that hand you a database and realtime plumbing. bonfireDB is an OSS clinical backend (Convex-like) designed to add typed clinical primitives, fresh-on-commit reads, ABAC-enforced semantic search, automatic audit, and FHIR R4 generated underneath. bonfireDB is early-stage and largely vision today.
bonfireDB is designed to be exactly that: a Convex-like TypeScript backend (TypeScript + Postgres + pgvector) but with FHIR R4 generated underneath and clinical authorization, consent, and audit built in. It's open source, runs in your AWS, and is in early access. Demand today is n=1 (it's us dogfooding).