bonfireDB vs Plain Postgres (roll-your-own)
Postgres + pgvector is a phenomenal, battle-tested substrate — but it ships none of the clinical primitives: no FHIR model, no search-parameter engine, no clinical authz, no audit, no terminology service. bonfire is the design that turns that same stack into a typed clinical backend, with scoped canonical FHIR R4 underneath instead of hand-built on top.
TL;DR
Plain PostgreSQL (roll-your-own) and bonfire share a stack — Postgres + pgvector — and the same strong ACID/MVCC consistency, so reads are fresh-on-commit in both; that is not a differentiator. The real difference is scope: with plain Postgres you build every clinical primitive yourself (the FHIR resource model and REST API, the search-parameter engine, versioning/history, clinical ABAC, AuditEvent/Provenance, terminology, bulk export, subscriptions), which is months-to-years of work and a permanent maintenance tax. bonfire’s positioning is to ship those primitives as typed clinical projections with ABAC enforced on read and write, automatic audit, built-in hybrid search, and agent context tools, with canonical FHIR R4 underneath. bonfire is early-stage and largely vision, so treat its column as design intent, not shipped maturity — whereas Postgres itself is about as battle-tested as software gets.
At a glance
Plain PostgreSQL is the maximum-control, maximum-work foundation — a world-class database with zero healthcare functionality — while bonfire is an opinionated clinical backend built on that same Postgres so you don’t hand-build the FHIR, authz, audit, and agent layers yourself.
| Plain Postgres (roll-your-own) | bonfireDB | |
|---|---|---|
| Type | General-purpose relational DB — not a healthcare/FHIR product | Agent-native clinical backend; canonical FHIR R4, typed reads on top |
| Language / stack | PostgreSQL (C) + pgvector; app tier in any language | TypeScript + Postgres + pgvector |
| License / cost | Free (PostgreSQL + pgvector BSD-style); pay infra + engineering | Planned Apache-2.0 core + managed tier |
| Hosting | Self-managed or managed (RDS/Aurora/Cloud SQL/Azure), HIPAA-eligible under BAA | Designed for your AWS or managed |
| App-native typed API | No — JSONB + SQL; you build every clinical primitive | By design — typed clinical primitives |
| Fresh-on-commit app reads | Yes — native ACID/MVCC strong read-after-write consistency | By design — committed operational read models |
| Reactive realtime cache | Primitives only (LISTEN/NOTIFY, logical decoding); no reactive layer | By design — useClinicalQuery |
| Built-in semantic search | pgvector primitive only; pipeline + result authz are DIY | By design — built in — hybrid (BM25 + vector), ABAC-enforced |
| Agent / MCP layer | None — no MCP/agent layer; you build it all | Agent context tools over cited evidence packets |
| Clinical authorization (write-enforced) | RLS + roles only; clinical ABAC/SMART/consent are your code | By design — read + write enforced ABAC, auto-audit |
| Automatic audit / provenance | WAL/triggers only; FHIR AuditEvent/Provenance hand-built | Automatic by design |
| FHIR conformance / export | None out of the box; full FHIR API, search, export, g10 from scratch | Canonical FHIR R4 (JSONB), typed reads on top; scoped conformance (honest: not a full enterprise FHIR server) |
| Best for | Teams/vendors with depth and time to build + certify the clinical layer themselves | Builders of AI-native health apps (scribes, copilots, agents) |
Where Plain Postgres (roll-your-own) genuinely wins
- Maximum control and zero lock-in: you own the data model, FHIR mapping, indexing, and authz exactly as you design them — no opaque server behavior, no per-resource pricing, no upstream roadmap dependency.
- Among the most battle-tested storage engines in existence: 35+ years, ACID + MVCC + strong read-after-write consistency, WAL/PITR, logical replication, a huge hiring pool, and deep operational tooling.
- Permissive free license (PostgreSQL License + pgvector BSD-style) — no software cost, fully usable inside a closed-source commercial product, no copyleft.
- One transactional store for relational data, JSONB documents, full-text search (tsvector/GIN), and vector search (pgvector 0.8.2, HNSW/IVFFlat) — hybrid filter+keyword+semantic queries over PHI with row authz at the same hop, no separate vector DB to sync.
- HIPAA-deployable today: RDS/Aurora/Cloud SQL/Azure are HIPAA-eligible under a BAA with encryption, HA, backups, and audit-friendly logging — the infrastructure compliance story is solid.
- Excellent primitives for the hard parts: Row-Level Security for tenant/row isolation, LISTEN/NOTIFY and logical decoding (wal2json/Debezium) for change streams, GIN/expression indexes for fast JSONB and FHIR-search-backing queries.
Where bonfireDB is built different
- App-native typed clinical primitives out of the box. Plain Postgres gives you JSONB tables and SQL — by its own docs it provides no FHIR support and no clinical model — so the entire resource model, validation, and REST API is yours to build. bonfire’s positioning is to ship those as typed projections.
- Clinical, write-enforced ABAC as a built-in. Postgres offers only infrastructure authz (roles/GRANT + Row-Level Security); SMART-on-FHIR scopes, Patient-compartment ABAC, consent, and break-glass are all application code you design and defend — easy to get subtly wrong, with a HIPAA-breach blast radius. bonfire’s design enforces ABAC on both read and write.
- Automatic audit and provenance. Postgres has WAL and triggers but no clinical audit model — FHIR AuditEvent/Provenance and immutable history must be hand-built. bonfire writes audit automatically.
- Built-in ABAC-enforced hybrid search. Plain Postgres has pgvector as a raw primitive, but the embeddings pipeline, chunking, reranking, and per-row authz on results are entirely yours to assemble. bonfire is designed to ship clinical hybrid search with ABAC applied to results.
- A reactive clinical query layer. Postgres has LISTEN/NOTIFY and logical decoding as building blocks, but FHIR Subscriptions plus per-subscriber authz on the change stream (the WALRUS-style problem) is real engineering you own. bonfire’s design exposes a reactive useClinicalQuery cache.
- canonical FHIR R4 underneath instead of hand-built on top. With plain Postgres there is no interop standard until you implement the search-parameter engine, _history, conditional ops (note: conditional-create returns 412 on ambiguous matches and is still race-prone), transaction bundles, and export — and conformance (ONC g10/US Core) is from scratch. bonfire provides scoped, canonical FHIR R4 so app teams don’t write that layer (honest: scoped, not a full enterprise FHIR server).
Which should you choose?
Choose Plain Postgres (roll-your-own) if…
Choose plain PostgreSQL (roll-your-own) if you need total control over the data model and FHIR semantics, have the engineering depth and time horizon to build and certify the clinical layer yourself, or you’re a server/EMR vendor where that layer is the product — and you want a free, boring-in-the-best-way, infinitely portable foundation with no vendor dependency.
Choose bonfireDB if…
Choose bonfire if you’re a small team shipping an outpatient or AI healthcare app and want the clinical primitives — typed projections, write-enforced ABAC, automatic audit, hybrid search, reactive reads, and canonical FHIR R4 — handed to you on the same Postgres stack rather than spending months-to-years hand-building and certifying them. Note bonfire is early-stage, so weigh its roadmap against Postgres’s proven maturity.
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
Can I just use plain Postgres for clinical data?
Yes, Postgres + pgvector is a solid, HIPAA-deployable foundation, but it ships no clinical primitives: no FHIR model, no search-parameter engine, no clinical ABAC, no audit, no terminology. You build and certify all of that yourself, which is months to years of work plus a permanent maintenance tax.
FHIR vs Postgres: what’s the actual difference?
Postgres is the storage substrate; FHIR is the clinical data model and API on top of it. With plain Postgres you hand-build the FHIR resource model, REST API, versioning, and search. bonfireDB is designed to keep scoped, canonical FHIR R4 in the same Postgres so app teams don’t write that layer.
Is building your own FHIR layer on Postgres worth it?
It can be if you’re an EMR/server vendor where the clinical layer is the product, or you need total control over FHIR semantics and have the engineering depth and time to build and certify it. For a small team shipping an outpatient or AI app, that’s months-to-years of undifferentiated work.
Does bonfireDB replace Postgres?
No. bonfireDB runs on the same Postgres + pgvector stack and inherits its ACID/MVCC consistency. It adds the clinical layer on top: typed projections, write-enforced ABAC, automatic audit, hybrid search, and canonical FHIR R4. bonfireDB is early access, so treat its capabilities as design intent, not shipped maturity.
Can pgvector handle semantic search over clinical notes?
pgvector gives you the raw vector primitive, but the embeddings pipeline, chunking, reranking, and per-row authz on results are entirely yours to assemble. bonfireDB is designed to ship clinical hybrid search with ABAC applied to results on the same Postgres hop, no separate vector DB to sync.