Why bonfireDB exists, and where it's going — in plain terms.
Doing it right means FHIR correctness, ABAC, consent, audit, and a BAA. So that layer gets hand-rolled — a second database for app state, a cron to rebuild projections, a homegrown audit log, a compliance surface nobody on the team wanted to own. We take that weight off you.
Build a product on it and you inherit a federation protocol: referential integrity you enforce by hand, write semantics that assume strangers, search that's a portability contract instead of a query language. You set out to ship a feature and end up operating a FHIR server. bonfireDB flips it — Postgres is the source of truth, FHIR is generated underneath, and you write typed clinical functions like any backend.
Agents over raw FHIR top out near 50% answer-correctness: they don't chase references, they filter on display text instead of codes, a single record is millions of tokens. That's an architecture problem, not a model one — so the fix lives in the data layer. We make the record legible: clean projections, resolved references and codes, and the part we're building that nobody ships yet — letting an agent read and aggregate the record while still respecting every patient's compartment and consent, under your BAA.
We don't claim a moat we haven't built — at this stage, our honesty is the product. We earn the trust one app, one agent, one audited read at a time, and we publish the benchmark so you never have to take our word for it.
bonfireDB is in early access. Join the waitlist and we'll get you in.