Comparison
Fire Arrow vs Supabase for healthcare
Supabase is an excellent general-purpose backend with Postgres, row-level security, and an auto-generated API. Fire Arrow targets healthcare specifically: the data model is FHIR, the authorization rules express clinical relationships, and the workflow primitives (CarePlans, Tasks, Subscriptions) are FHIR-native.
Who this is for
Architects, CTOs, staff engineers, and product leaders evaluating FHIR infrastructure options.
Clinical applicability
A patient app whose primary data is Observations, MedicationRequests, QuestionnaireResponses, and Tasks benefits from FHIR resources as the model. An app whose primary data is bookings, payments, or content can stay on a general-purpose backend and use FHIR only at integration boundaries.
Capability comparison
When to choose Supabase for healthcare
Your product uses a custom schema and your team is prepared to own clinical data modelling, healthcare interoperability, and authorization policy design at the table level.
When to choose Fire Arrow
You want FHIR-native resources, healthcare-aware authorization validators, GraphQL over FHIR, and clinical workflow concepts without designing them from raw tables.
Related pages
FAQ
Can I use Fire Arrow alongside Supabase?
Technically yes, but for most healthcare products it is not the architecture we would recommend. FHIR is expressive enough to model the large majority of what a healthcare product needs, and going all in on the FHIR backend keeps the access boundary in one place. Adding a second backend that holds clinical or patient-related data introduces a real risk of side-channel access paths that bypass Fire Arrow's RBAC, especially when sensitive data is mirrored or denormalised across the two systems. The pattern works when the second backend is strictly limited to non-sensitive, non-RBAC-bound data: internal operations like license issuance, marketing site content, or product analytics that do not contain patient information. Identity should still be unified through your OAuth/OIDC provider in that case.
Does Fire Arrow handle file uploads?
Server has a `$binary-upload` operation backed by Azure Blob Storage. For non-clinical files, a general-purpose object store remains a reasonable choice.
