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 FHIR R4 generated underneath instead of hand-built on top.
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 semantic search, and a build-your-own-MCP surface, generating 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.
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; FHIR generated underneath |
| Language / stack | PostgreSQL (C) + pgvector; app tier in any language | TypeScript + Postgres + pgvector |
| License / cost | Free (PostgreSQL + pgvector BSD-style); pay infra + engineering | Apache-2.0 core (free) + managed tier |
| Hosting | Self-managed or managed (RDS/Aurora/Cloud SQL/Azure), HIPAA-eligible under BAA | Your AWS (OSS) or managed |
| App-native typed API | No — JSONB + SQL; you build every clinical primitive | Yes — typed clinical primitives |
| Fresh-on-commit app reads | Yes — native ACID/MVCC strong read-after-write consistency | Yes — committed operational read models |
| Reactive realtime cache | Primitives only (LISTEN/NOTIFY, logical decoding); no reactive layer | Yes — useClinicalQuery |
| Built-in semantic search | pgvector primitive only; pipeline + result authz are DIY | Built in — pgvector, ABAC-enforced |
| Agent / MCP layer | None — no MCP/agent layer; you build it all | Build-your-own-MCP over clean projections |
| Clinical authorization (write-enforced) | RLS + roles only; clinical ABAC/SMART/consent are your code | Read + write enforced ABAC, auto-audit |
| Automatic audit / provenance | WAL/triggers only; FHIR AuditEvent/Provenance hand-built | Automatic |
| FHIR conformance / export | None out of the box; full FHIR API, search, export, g10 from scratch | FHIR R4 generated underneath; 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) |
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 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, semantic search, reactive reads, and generated FHIR — 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.
Open source. Runs in your AWS. The clinical layer is handled.
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.
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 generate scoped FHIR R4 underneath the same Postgres so app teams don't write that layer.
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.
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, semantic search, and generated FHIR R4. bonfireDB is early access, so treat its capabilities as design intent, not shipped maturity.
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 semantic search with ABAC applied to results on the same Postgres hop, no separate vector DB to sync.