bonfireDB vs Firely Server (Vonk)
Firely Server, from FHIR’s co-creators, is a mature ONC §170.315(g)(10)-certified FHIR server — the right call when conformance and validation are the product. bonfire is an early-stage clinical backend (planned Apache-2.0 core) that treats app-state, fresh-on-commit reads, ABAC, and agents as first-class, with canonical FHIR R4 underneath rather than making you build apps on top of it.
TL;DR
Firely Server is a genuine, certified, native FHIR server (STU3/R4/R5) built by the people who helped initiate FHIR, with best-in-class conformance, validation, version history, terminology operations, and a documented .NET plugin/Facade architecture — if you must prove regulatory interoperability, it is a top-tier choice. It is, however, a server and not an app platform: it is an OAuth2 resource server (bring your own IdP), authorization is SMART-scope/compartment-based rather than per-row ABAC, it is closed-source with contact-sales pricing, self-hosted only with no production managed SaaS, and it has zero semantic/vector/agent tooling. bonfire is much earlier — largely vision and design rather than shipped scale — so the honest comparison is Firely’s proven breadth versus bonfire’s positioning: typed clinical primitives, fresh-on-commit operational reads, a reactive cache, write-enforced ABAC with automatic audit on by default, and built-in hybrid search (BM25 + vector) you can hand to an agent via your own MCP. Choose Firely to be a compliant FHIR endpoint at enterprise scale; choose bonfire to ship an outpatient or AI-native app fast without bolting a second database and an entire auth/AI layer onto a FHIR store.
At a glance
Firely Server (Vonk) is the certified, conformance-first FHIR data layer you buy to prove interoperability; bonfire is the clinical app backend (planned Apache-2.0 core) you build on when one team needs fresh reads, ABAC, and AI over their own data.
| Firely Server (Vonk) | bonfireDB | |
|---|---|---|
| Type | Commercial, certified turn-key native FHIR server (formerly Vonk) | Agent-native clinical backend; canonical FHIR R4, typed reads on top |
| Language / stack | .NET / C# on Firely .NET SDK; community edition is SQLite-only, SQL Server / MongoDB on paid tiers | TypeScript + Postgres + pgvector (Postgres-first, no Redis) |
| License / cost | Closed-source; flat-fee annual license, contact-sales (no public pricing) | Planned Apache-2.0 core + managed tier |
| Hosting | Self-hosted only (anywhere); no production managed SaaS | Designed for your AWS or managed |
| App-native typed API | No — FHIR server, not an app platform; BYO app/business logic | By design — typed clinical primitives |
| Fresh-on-commit app reads | FHIR-search-backed; no guaranteed read-your-write app contract | By design — committed operational read models |
| Reactive realtime cache | Dated: STU3/R4 rest-hook subscriptions only; no WebSocket push | By design — useClinicalQuery |
| Built-in semantic search | None — no vector/embeddings/RAG (verified) | By design — built in — hybrid (BM25 + vector), ABAC-enforced |
| Agent / MCP layer | None built in; 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) | OAuth2 resource server; SMART scopes + compartments, BYO IdP | By design — read + write enforced ABAC, auto-audit |
| Automatic audit / provenance | Tamper-resistant BALP AuditEvents, but plugin-enabled + paid Scale tier | Automatic by design |
| FHIR conformance / validation / terminology | Best-in-class: native STU3/R4/R5, ONC g(10), US Core, SMART certified; full validation + terminology ops ($validate-code/$expand/$lookup/$translate) | Canonical FHIR R4 / core profiles (JSONB), typed reads on top; scoped conformance (honest: not a full enterprise FHIR server) |
| Best for | Enterprises/regulated orgs needing certified, validation-grade FHIR | Builders of AI-native health apps (scribes, copilots, agents) |
Where Firely Server (Vonk) genuinely wins
- Best-in-class FHIR conformance and validation, built by FHIR’s co-creators, with real ONC §170.315(g)(10) certification (2025, Cert #15.04.04.3143.Fire.06.01.0.250502), US Core 7.0.0 / USCDI v4, and SMART App Launch 2.2.0 — if you must prove interoperability, this is top-tier.
- A true native FHIR store across STU3/R4/R5 with full per-resource version history, batch/transactions, chaining and reverse-chaining (_has), _include/_revinclude, custom SearchParameters, and a managed conformance/Administration API.
- First-class validation and terminology: profile/StructureDefinition validation plus full terminology operations ($validate-code/$expand/$lookup/$translate/$subsumes) with local and remote terminology routing — the depth you want when correctness against US Core and code systems is the bar. (SNOMED CT is free for US use via the NLM UMLS license.)
- A genuinely free on-ramp: the community edition runs on SQLite at no cost for evaluation and low-volume use, before stepping up to the licensed production tiers (SQL Server / MongoDB).
- Predictable flat-fee annual licensing not metered on data volume, API calls, users, or patients — financially sane as you scale, the opposite of usage-priced cloud FHIR services.
- Deploy-anywhere control: .NET Core on Windows/Linux/macOS, Docker, Kubernetes (Helm), any cloud or on-prem — strong for data-residency, BAA, and air-gapped requirements.
- Tamper-resistant, BALP-conformant AuditEvent generation — AuditEvents can’t be updated or deleted via the REST API — for regulated, audit-grade deployments.
- Backed by a real company (consulting, training, Simplifier.net profiling, enterprise support) with 6+ major versions, a regular release cadence, and named users like UCSF, Humana, Roche, and the WHO — low abandonment risk.
Where bonfireDB is built different
- Fresh-on-commit operational reads: bonfire’s design serves app reads from committed read models instead of routing UI through FHIR search indexes — Firely is a FHIR server first, so app-facing query freshness is whatever your search backend gives you, not a guaranteed read-your-write contract.
- Reactive realtime cache for app clients: bonfire is designed to ship useClinicalQuery; Firely’s realtime is dated for app push — subscriptions are STU3/R4-style, rest-hook channel only, with no R5 topic-based framework and no native WebSocket push to clients (verified), and full event streaming (PubSub via Kafka/RabbitMQ) is a paid Scale add-on needing DB change-data-capture.
- Write-enforced clinical ABAC: bonfire enforces per-row read AND write authorization. Firely authorizes via SMART scopes, compartments, and AccessPolicy-style search filters rather than clinical ABAC (BYO IdP / separate Firely Auth product), with the sharp edge that resources outside a configured compartment are not access-controlled and per-row ABAC isn’t first-class (verified).
- Built-in, ABAC-enforced hybrid search: bonfire embeds hybrid search (BM25 + vector) with authz applied per hit. Firely Server has zero vector/semantic search, embeddings, or RAG (verified) — you’d build that entire layer yourself alongside the FHIR store.
- Agent-native via context tools over cited evidence packets: Firely has no built-in agent/MCP/LLM tooling (verified), so an AI app on Firely starts from scratch on the query-aware clinical context layer that FHIR-AgentBench points toward.
- App-state and audit posture for a single team: app/draft/workflow state is a first-class home in bonfire (no second database), and automatic audit + provenance is on by default — whereas Firely’s tamper-resistant AuditEvent generation, while real and BALP-conformant, requires explicitly enabling Vonk.Plugin.Audit and is gated to the paid Scale / Prior-Auth tiers (verified).
Which should you choose?
Choose Firely Server (Vonk) if…
Choose Firely Server if you need a certified, validation-grade FHIR endpoint — ONC g(10), US Core, SMART App Launch — to prove interoperability to payers, regulators, or partners, with predictable flat-fee licensing, deploy-anywhere control, full version history, and the backing of FHIR’s co-creators. It is the buy-not-build choice when conformance is the product and you’re prepared to bring your own auth, AI, and app layer in .NET.
Choose bonfireDB if…
Choose bonfire if you’re a founder shipping an outpatient or AI-native app and want fresh-on-commit reads, a reactive cache, write-enforced ABAC with audit on by default, and hybrid search an agent can call via your own MCP — without standing up a second database and an entire auth/AI stack on top of a FHIR server. Pick it knowing it’s early-stage and offers scoped (not full enterprise) FHIR conformance, with canonical FHIR R4 underneath.
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
Is bonfireDB a Firely Server alternative?
Only for some use cases. Firely Server (Vonk) is a certified native FHIR server built for conformance and validation. bonfireDB is an app backend above your canonical FHIR R4 (not a FHIR server), designed for fresh-on-commit reads, write-enforced ABAC, and AI. If you must prove ONC g(10) interoperability, Firely is the right tool; if you’re shipping an outpatient or AI app fast, bonfireDB fits better. bonfireDB is early access.
What does Firely Server (Vonk) do that bonfireDB doesn’t?
Firely Server is a certified, validation-grade FHIR server: ONC §170.315(g)(10), US Core, SMART App Launch, full STU3/R4/R5 history, and complete terminology operations ($validate-code, $expand, $lookup, $translate). bonfireDB offers scoped canonical FHIR R4 underneath, not a full enterprise FHIR server, and is honest about that.
Does Firely Server have vector or semantic search for clinical notes?
As of 2026, no. Firely Server (Vonk) has zero built-in vector search, embeddings, or RAG, so you’d build that layer yourself. bonfireDB is designed with built-in hybrid search (BM25 + vector), ABAC-enforced per hit, that an agent can call via your own MCP. Verify current Firely capabilities before deciding.
How does authorization differ between Firely Server and bonfireDB?
Firely Server is an OAuth2 resource server using SMART scopes and FHIR compartments, with a separate IdP — per-row ABAC isn’t first-class, and resources outside a configured compartment aren’t access-controlled. bonfireDB is designed to enforce per-row read and write ABAC with automatic audit on by default.
Is Firely Server open source, and what does it cost?
As of 2026, Firely Server (Vonk) is closed-source with flat-fee annual licensing and contact-sales pricing; a free SQLite community edition exists for evaluation. bonfireDB’s core is planned as Apache-2.0 (free) with an optional managed tier. Verify current Firely pricing before deciding.