bonfireDB is pre-launch. We're building it in public, in order, and we mark what's in progress vs what's ahead unmistakably. This is the real sequence — the same plan we build to internally — so you can see exactly what each stage is and what it unlocks. A backend you trust starts with a roadmap you can trust.
You own one Postgres database. You write typed clinical functions (clinical.observations.record()) instead of raw FHIR. Common reads are kept fresh inside the write transaction and pushed to your UI reactively. FHIR R4 is generated underneath for export and interop — we are not a FHIR server you program against; we're the app backend above one. And the part that's the moat: an agent layer that lets an LLM read — and safely aggregate — the record without ever crossing a patient's boundary. Everything below is how we get there, in order.
How to read the status: Building now = in active development. Next / Then = sequenced, designed, not yet built. Later = committed direction, undated. If a stage isn't marked "Building now," assume it isn't shipped.
The base everything sits on — and the single hardest, riskiest piece, built first because the whole agent layer depends on it being airtight.
Make authorization, consent, and audit a single unbypassable path — not something each handler has to remember.
Your UI reflects the database without you wiring up invalidation.
Subscribe to a read model; when a write commits, the change is pushed to the client in commit order.
LISTEN/NOTIFY for low latency + a write-ahead-log backstop for ordered, durable catch-up after a disconnect. No Redis, no separate broker.
Every write tells you which views are fresh and which heavy indexes are still pending — so nothing silently rots.
Be a real SMART app and a clean interop citizen — without running a FHIR server.
Agents over raw FHIR cap near 50% answer-correctness — an architecture problem, not a model one. This is the layer that breaks it. The MCP builder →
The second badge, and the receipts. Agents can't do cohort questions over raw FHIR — the leading benchmark literally excludes them. We make aggregation answerable, with the authorization nobody else ships, and we publish the eval.
Ask "how many of my patients scored ≥10 on PHQ-9 this month" — answered over the same projections, scoped to your compartment and consent, with small-cell suppression so a cohort can't leak an identity. App-scale, never cross-org.
Reproducible eval: raw FHIR + Medplum-MCP-as-shipped vs the bonfireDB layer — same model, same data, held-out, multi-model. Published method and harness. See the eval →
Honest status on the benchmark: the ~50% ceiling is the published, peer-reviewed result we're attacking. The bonfireDB before/after is a capability claim with an open methodology — not a measured number we're asking you to trust yet. When we run it, we publish the harness with it (reproducible by any independently credentialed researcher).
Committed direction, sequenced by what design partners actually need — undated.
We're rebuilding TicVision — our own Tourette's symptom-tracker (a React Native app on a bespoke DynamoDB backend) — on bonfireDB, and shipping it as a SMART-on-FHIR app. Every stage above has to be real enough to delete TicVision's hand-built database, its CRUD, and its hand-rolled HIPAA audit log. If a stage can't carry our own app, it isn't done. The TicVision rebuild →
Land as the agent-native operational store, then become the backend the next generation of AI-native health apps are built and run on — agents that read and aggregate the record safely under BAA. We don't claim a moat we haven't built; at this stage, our honesty is the product. We earn it one app, one agent, one audited read at a time. Read the vision →
bonfireDB is in early access, built in the open. Join the waitlist and follow along — or come build a stage with us as a design partner.