HAPI FHIR vs Blaze: which FHIR server to choose

When to choose HAPI FHIR or Blaze

Choose HAPI FHIR when the core job is a FHIR API that many clients and integrations will hit. HAPI's JPA server covers FHIR DSTU2, DSTU3, R4, R4B and R5, so a team serving partners that still exchange older versions has a path that Blaze, which implements large parts of the R4 API, does not offer. HAPI also gives you terminology services, validation, MDM and partitioning, which matter when you separate data by tenant, region or source system. Its relational storage is backed by PostgreSQL or Microsoft SQL Server in production, so your database team can run the server with tooling they already know. Expect to own more of the security design yourself: HAPI provides building blocks such as the AuthorizationInterceptor and BALP audit logging, not a single finished security layer.

Choose Blaze when the core job is CQL evaluation over a large patient population, such as a research cohort or quality-measure program that depends on $evaluate-measure and $cql. Blaze's internal CQL engine is the reason it exists, and its indices live in an embedded RocksDB store, which favors read-heavy analysis over high-volume concurrent writes. Its write pattern is the main constraint to test before you commit: all write transactions run strictly one at a time from a single transaction log, so a large bundle delays smaller writes behind it. If your feeds arrive as large batches, plan to load them during quiet hours and keep transactions small, as the project advises. Blaze's authentication is built around Keycloak, so confirm that your identity team can operate it. The decision turns on workload shape, write pattern, terminology needs, auth model and whether your operating team is more fluent in Java and PostgreSQL or in Keycloak and RocksDB-based tooling.

Which platform fits which scenario

This table maps common HAPI FHIR and Blaze scenarios to the platform that fits better and the condition that decides it. Read each row as a starting point, then confirm the condition against your own workload, data volumes and identity setup before shortlisting.

Scenario	Better fit	Condition that makes it so
Multi-version FHIR facade for EHR integration	HAPI FHIR	HAPI FHIR JPA covers DSTU2, DSTU3, R4, R4B and R5, so it suits mixed-version partners. Confirm which FHIR versions your interfaces need before deciding.
Cohort or quality measure pipeline with CQL	Blaze	Blaze has a built-in CQL engine and supports $evaluate-measure and $cql, which fits research cohorts and measures. If your measures need only occasional evaluation, HAPI FHIR with an external engine may also work.
High-volume transactional workload with bulk loads	HAPI FHIR	Blaze runs all write transactions one at a time from a single log, so a large bundle delays smaller writes. HAPI FHIR JPA is a better fit when mixed concurrent writes matter more than read-heavy analytics. Test your own bundle sizes.
Team already running PostgreSQL	HAPI FHIR	HAPI FHIR JPA supports PostgreSQL and Microsoft SQL Server for production, so existing database operations carry over. Blaze stores indices in embedded RocksDB, so PostgreSQL skills apply less directly.
Team already running Kafka	Blaze	Blaze's distributed variant uses Kafka as its transaction log and the project describes horizontal scaling through it. Confirm the distributed setup with the Blaze maintainers before relying on it in production.
Team needing a Keycloak-based login	Blaze	Blaze uses Keycloak as its currently supported auth provider. HAPI FHIR has no single security layer and relies on building blocks such as the AuthorizationInterceptor, so you would assemble and maintain that integration yourself.
Partitioned multitenancy or regional data separation	HAPI FHIR	HAPI FHIR JPA partitioning places resources in partitions for multitenancy or regional grouping. Confirm whether Blaze's storage model meets your tenancy isolation requirements.

How each server is built and what that means for operations

HAPI FHIR and Blaze make different bets about where state lives and how writes flow. Each choice changes who patches what, which database team you need, and how a bad transaction affects everyone else. The cards below cover the components you will operate and the checks to make before committing.

HAPI JPA server on a relational database

HAPI's JPA server stores FHIR resources through the JPA API, so the database is a choice you make rather than a fixed part of the product. For production, the starter supports PostgreSQL and Microsoft SQL Server, while its embedded H2 default is for trial use and MySQL is not supported. Your DBA team owns backups, indexing, sizing and failover. Confirm which database version your chosen HAPI release is tested against before you pick one.

HAPI deployment paths

The starter can run as the hapiproject/hapi Docker image, under Docker Compose, under Spring Boot, as a WAR on Tomcat, Jetty or Wildfly, or on Kubernetes with a Helm chart. Each path puts the same server into a different patching cycle, so the choice follows your platform team's existing runtime. A WAR on an application server suits a team that already runs Java app servers. A container image suits a team that deploys through Kubernetes pipelines.

Blaze ingress, frontend and backend

Blaze's architecture places an nginx ingress in front of a frontend web UI and a backend that serves the FHIR API and an Admin API. Operating it means running at least these three parts and routing traffic between them correctly. Ask your team who owns the nginx configuration and TLS certificates, because that layer is part of the production surface even when the FHIR logic is not. Confirm the exact container layout against the current architecture document before you size hosts.

Keycloak as the supported identity provider

Blaze uses Keycloak as its currently supported auth provider, so authentication depends on a Keycloak realm, its client configuration and its upgrade cycle. If your organization already standardizes on another identity provider, this is a real integration cost, not a configuration detail. HAPI FHIR instead gives you authentication interceptors and an AuthorizationInterceptor to wire to your own provider, which means you write and test that logic yourself. Map who manages each side before comparing effort.

RocksDB indices and transaction log

Blaze keeps its indices in an embedded RocksDB key-value store, and its transaction log uses RocksDB in the standalone deployment or Kafka in the distributed variant. Standalone is simpler to run but leaves storage tied to a single node. The distributed variant adds a Kafka cluster to operate, and the project states that Blaze scales horizontally through that variant. Ask whether your team has Kafka skills before choosing the distributed path.

Serialized writes and transaction size

Blaze runs all write transactions strictly one at a time from a single transaction log, so one very large transaction bundle can block smaller writes that arrive after it. The documentation advises keeping transactions small and loading very large datasets during low interactive load. HAPI's relational model handles concurrent writes through the database, so bulk loads there are a tuning question rather than a queue. Test your largest real bundle against each server during the proof of concept, and plan a load window if you choose Blaze.

Capability comparison on supplied facts

This table sets HAPI FHIR's JPA server against Blaze on the capabilities that usually decide a shortlist, using only facts we can source. Read each row as a question to answer in your own environment: where a cell says to confirm, test that behavior against a realistic load and your identity provider before you commit.

Capability	HAPI FHIR (JPA server)	Blaze
FHIR version coverage	DSTU2, DSTU3, R4, R4B and R5 are documented	Implements large parts of the FHIR R4 API
Terminology services	Terminology services are documented; confirm LOINC and SNOMED CT loading for your code systems	LOINC and SNOMED CT supported with $validate-code and $expand
CQL and measure operations	Not a built-in focus; confirm any CQL or measure tooling you need	Internal CQL engine with $cql and $evaluate-measure
Storage engine	Database-backed via the JPA API, not tied to one database technology	Embedded RocksDB indices with a RocksDB or Kafka transaction log
Supported databases	Embedded H2 by default; PostgreSQL and Microsoft SQL Server for production; MySQL not supported	Storage is embedded RocksDB; no external relational database is part of the supplied facts
Partitioning and multitenancy	Resources placed in partitions for multitenancy, separate data sources or regional grouping	Confirm tenant isolation approach with the project before relying on it
Authentication building blocks	Authentication interceptors and AuthorizationInterceptor; no single security layer, so you assemble the design	Keycloak is the currently supported auth provider
Audit logging	BALP audit logging and consent and search narrowing interceptors are available	Confirm audit logging coverage in the Admin API and backend documentation
Horizontal scaling	Scale depends on your database and deployment choices; confirm with your architecture	Scales horizontally via its distributed storage variant with Kafka

License terms and paid support paths

HAPI FHIR is a Java API for HL7 FHIR clients and servers, licensed under the Apache Software License 2.0. That license lets your team use, modify and redistribute the library and JPA server without a license fee. The project's README does not sell a paid edition of its own. Instead, it points readers to Smile CDR for commercial support, which is a separate product from the same company family and carries its own agreement.

License scope: The Apache 2.0 terms cover the open-source HAPI FHIR code. They do not cover any Smile CDR product, which you would license separately.
Support pointer: The README directs teams that need commercial support to Smile CDR, so a support contract is a purchase decision, not a feature of the free project.
Community channels: Without a commercial contract, support depends on public project channels and your own engineering capacity. Plan for that if you choose the open-source route.
Public demonstration server: The hapi.fhir.org server is a demonstration environment. It is not a production service and carries no support commitment.
Derivative work: If you build a custom platform on HAPI, your own code and configuration follow your own license terms, and your team owns the upgrade and patch cycle.

Ask Smile CDR which of its products, support levels and release commitments apply to your HAPI version and deployment model, and get the terms in writing before you rely on them for a regulated system.

How Blaze's single write queue changes bulk loading

Blaze runs all write transactions strictly one at a time from a single transaction log, so a large transaction bundle blocks smaller writes submitted after it. For a team that loads data in bulk while clinicians or applications write small updates, this is the constraint that decides whether Blaze fits. The Blaze architecture documentation advises keeping transactions small and loading very large data during low interactive load, which is an operating rule you would need to enforce, not a configuration you can switch off.

HAPI FHIR's JPA server writes through its database layer, so the write path is governed by the database, its connection pool and the transaction boundaries you configure in the server, with PostgreSQL or Microsoft SQL Server as the production options. That model does not force every write through one ordered log, so a bulk import and a small interactive write do not necessarily queue behind each other in the same way. The trade-off is that you must size the database, the connection pool and the batch settings yourself, and tune them against your own data shape. Confirm both behaviors with a load test that mixes your real bundle sizes with your real interactive traffic, rather than relying on a general claim about either product.

The ingest pattern decides which constraint matters. If your workload is mostly steady, small writes from applications with a predictable overnight bulk load, Blaze's ordering is a manageable rule and its indices and measure evaluation may outweigh the cost. If you receive large, unscheduled bundles from upstream systems during business hours, the single queue becomes an availability risk and you should plan for scheduled windows, bundle splitting or a different server model. Ask Blaze's maintainers how the single log behaves at your expected volume, and record the answer in your design before you commit to either platform.

Authentication and authorization on each server

HAPI FHIR gives you interceptors and hooks to assemble access control, while Blaze currently ships with Keycloak as its supported auth provider. The cards below set out what your team builds or configures on each side, and what to confirm with each project before you commit to a design.

HAPI assembles security from building blocks

HAPI FHIR states that it does not provide a single one-size-fits-all security layer. Instead it offers authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging. Your team chooses which to enable and wires them to your identity provider. Expect to write the rules that map users and clients to resource access, then test them against your own compartment and consent model.

Authorization rules are your responsibility

With HAPI, the AuthorizationInterceptor is a mechanism, not a policy. Someone on your team must decide which scopes grant read, write or search on which resource types and patient records, and encode those decisions in code. Review these rules with your security and privacy staff before go-live, and include negative tests that confirm a token cannot reach records outside its patient context.

Blaze relies on Keycloak

Blaze's architecture uses Keycloak as its currently supported auth provider, alongside an nginx ingress, a frontend web UI and a backend that exposes the FHIR API and an Admin API. If your identity estate already runs Keycloak, the integration path is the documented one. If your organization standardizes on another identity product, confirm with the Blaze project whether it can be placed in front of the server and how it would be supported.

Blaze fixes the identity boundary

Because Keycloak is the currently supported provider, Blaze's access model is narrower to change than HAPI's. Your team works within the components and roles the project defines rather than writing its own authorization layer. Ask the project how Keycloak roles map to FHIR operations, which operations the Admin API exposes, and how the frontend UI is restricted to administrators.

Audit trails and consent

HAPI FHIR documents BALP audit logging and consent interceptors as options you can enable, so audit and consent coverage depends on what your team configures. For Blaze, confirm what audit events the server records, where they are stored, and whether consent decisions can be enforced at the resource or patient level. Ask both projects for a written description of their logging before your compliance team relies on it.

Network edge and CORS

HAPI FHIR includes CORS support that you configure for browser-based clients. Blaze places an nginx ingress in front of the backend, so TLS termination, request limits and browser access are handled at that layer. Decide where authentication is enforced, at the ingress, in the application, or both, and document it so that no path to the FHIR API bypasses the check.

What drives running cost for each server

This table sets the running cost drivers for HAPI FHIR's JPA server against Blaze across infrastructure, staff skills, upgrades, support and integration work. Read each row as a question to put to your team and to any quote, because the cost sits with whoever operates the stack. The main takeaway is that HAPI carries database and JVM operations, while Blaze carries RocksDB, Keycloak and, in distributed form, Kafka.

Cost driver	HAPI FHIR (JPA server)	Blaze
Database and message infrastructure	A relational database is required. The starter supports PostgreSQL and Microsoft SQL Server for production and defaults to embedded H2, so plan for a managed or self-run database with backups and failover.	Indices sit in an embedded RocksDB store. The standalone deployment uses RocksDB for its transaction log, while the distributed variant uses Kafka, which adds a cluster to operate.
Staff skills	Teams need JDK 17 for HAPI FHIR 8.2.0, plus Java and Spring Boot operations, or WAR deployment on Tomcat, Jetty or Wildfly.	Teams need Keycloak administration, nginx ingress, and familiarity with RocksDB tuning and, for the distributed variant, Kafka operations.
Upgrade effort	Each release may move the JDK baseline and server dependencies. Confirm the migration path between your current and target HAPI FHIR version before scheduling work.	Confirm how schema or index changes are handled between releases such as v1.11.0 and later, and whether reindexing is needed.
Support options	Free community support is available through the project. Commercial support is provided by Smile CDR, which the HAPI FHIR README points to, so ask whether a support agreement is in scope.	Blaze is an Apache 2.0 project from the Samply community. Ask any vendor you engage whether it offers paid support, and what response terms apply.
Integration and customization work	Authorization, consent and audit logging use HAPI's building blocks (AuthorizationInterceptor, consent and BALP), which your team or a partner must configure and test.	Keycloak is the supported auth provider, so identity integration, realm setup and any custom terminology loading are work you own.
Who is paid for what	Internal platform staff or an implementation partner are paid for deployment, database operations, JVM tuning and interceptor work. Software licensing is not charged by the open-source project.	Internal platform staff or an implementation partner are paid for RocksDB and Keycloak operations, ingress setup and, if chosen, Kafka operations. Software licensing is not charged by the open-source project.
What to ask for in a quote	Ask for a written scope covering database sizing, JDK and Spring version pinning, interceptor configuration, backup and restore tests, and the upgrade plan.	Ask for a written scope covering storage and transaction log design, Keycloak configuration, transaction-size guidance for bulk loads, backup procedures and upgrade testing.

Moving data and clients from one server to the other

This sequence moves FHIR resources, search behavior and client connections from HAPI FHIR to Blaze in a controlled order, so each stage has a check before the next one starts. It also makes clear which parts of the old setup carry over and which must be rebuilt on the Blaze side.

Inventory resources, profiles and custom code
Start by listing every resource type in use, the FHIR versions your clients speak, the profiles and extensions you validate against, and any custom operations, interceptors or authorization rules you wrote on the HAPI side. Assign an owner to each item, usually your integration lead with a platform engineer. The output is a written inventory that separates standard FHIR content from anything that depends on HAPI-specific code. Confirm early that Blaze supports the FHIR R4 interactions you rely on, because Blaze implements large parts of the R4 API rather than every version HAPI serves.
Map search parameters and terminology bindings
Compare the search parameters your clients use against what Blaze exposes, and check how each code system is loaded and expanded. Terminology services differ between the two servers, so confirm that LOINC, SNOMED CT and any local value sets resolve the same way on the target. Record every gap as either a client change or a data change. The output is a mapping sheet that a test team can run queries against. Ask Blaze's maintainers or your own test results to confirm behavior for any search modifier you depend on.
Export resources through the FHIR API
Export data from the HAPI server using standard FHIR read and search calls, or bulk export if your HAPI deployment enables it, rather than copying database tables directly. Export by resource type and keep references intact so that Patient, Encounter and Observation links still resolve. Store the exported bundles with checksums and a record of counts per type. The output is a verified export set with a count reconciliation against the source, which becomes your baseline for the reload.
Load into Blaze in small transactions
Load the exported data into a non-production Blaze instance first. Blaze runs all write transactions one at a time from a single transaction log, and a large transaction bundle blocks smaller writes submitted after it. Split the load into modest batches, and run the largest loads during low interactive use, as the Blaze documentation advises. The output is a loaded test instance with load timings recorded per batch, which tells you how long the production load window needs.
Validate counts, references and search results
Reconcile resource counts per type against the export baseline, then run a fixed set of reference and search queries against both servers and compare results. Check that CQL libraries and measure evaluations you rely on produce the same outputs on identical data, since CQL libraries are rebuilt rather than moved. Validate a sample of resources against your profiles. The check is complete when counts match, the query comparison shows no unexplained differences, and each difference has a recorded decision.
Rebuild authentication, authorization and auditing
Rebuild access control on Blaze rather than copying HAPI configuration. Blaze uses Keycloak as its currently supported auth provider, so define realms, clients, scopes and roles there, then map each HAPI authorization rule, consent check and audit requirement to a Blaze control. HAPI offers interceptor-based building blocks, so do not assume a one-to-one match. Test each client role with a token that should be refused as well as one that should succeed. The output is a signed-off access matrix and passing negative tests.
Repoint clients in stages
Move clients one at a time, starting with read-only consumers, then moving write-heavy integrations last. Change base URLs, token endpoints and any HAPI-specific headers or operations the client calls, and keep the HAPI server running in read mode for rollback until each client has passed its checks. Keep a dated log of which client moved and when. The output is a client inventory where every entry shows its cutover date, its test evidence and its rollback path.
Retire the HAPI store after a verified period
Once every client has run on Blaze and your audit and backup checks pass, freeze writes on HAPI, take a final verified backup, and then decommission the server and its database. Keep the backup under your retention policy, since clinical records and audit trails may need to remain available beyond the migration. Confirm with your compliance owner what evidence the migration must retain. The output is a decommissioning record that lists the final backup location, its checksum and the approval for removal.

Where FHIR server projects usually run long

Terminology and profile validation are where most FHIR projects find their true scope, and they cost different amounts on each platform. On HAPI FHIR, the JPA server documents terminology services and validation as built-in features, so the work is mostly configuring code systems, loading value sets and deciding which profiles the server enforces on write. On Blaze, the documented terminology support covers LOINC and SNOMED CT, with $validate-code and $expand. If you need other code systems, custom value sets or profile enforcement on write, confirm the loading path and validation behavior with the Blaze project before you scope the work. Ask any implementation partner to list every code system and profile in scope, and to state which ones load at install time and which are updated later.

Authentication integration and bulk loading are where the two platforms differ most in effort. HAPI FHIR provides building blocks, including authentication interceptors, the AuthorizationInterceptor, consent and search narrowing, and BALP audit logging, but it does not supply a single security layer. The identity provider connection, scope mapping and audit design are therefore your build. The Blaze architecture documentation names Keycloak as its currently supported auth provider, which narrows the identity decision but ties you to that stack if your directory sits elsewhere. For loading, Blaze runs all write transactions strictly one at a time, so one large transaction bundle delays smaller writes queued behind it. Plan a loading window at low interactive load and keep bundles small. On either platform, measure load time against the database you choose before you commit to a schedule.

Questions buyers ask before choosing a FHIR server

Can a team run HAPI FHIR or Blaze without a vendor contract?

Yes. HAPI FHIR is licensed under the Apache Software License 2.0, and its JPA server starter can be deployed as a Docker image, with Docker Compose, with Spring Boot, as a WAR on Tomcat, Jetty or Wildfly, or on Kubernetes with a Helm chart. Blaze is also open source under Apache 2.0 and can be started with a single docker run command. Running either one alone means your team owns upgrades, database operations, backups, monitoring and security configuration. The HAPI README points to Smile CDR for commercial support. The supplied facts do not name a commercial support path for Blaze, so confirm that with its maintainers before you depend on one.

What work does the team have to supply in each server?

With HAPI FHIR, your team assembles security from building blocks. HAPI states it does not provide one-size-fits-all security, so you configure authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS and BALP audit logging to match your access policy. You also choose a database: the starter defaults to embedded H2, supports PostgreSQL and Microsoft SQL Server for production, and does not support MySQL. With Blaze, the supported auth provider is Keycloak, so identity work centers on a Keycloak realm, and you operate the nginx ingress, frontend, backend and Admin API. In both cases, terminology loading, validation settings and backup routines are your responsibility.

Can Blaze serve general API traffic with many concurrent writers?

Blaze implements large parts of the FHIR R4 API, but its write path is the constraint to test first. Blaze runs all write transactions strictly one at a time from a single transaction log, so a large transaction bundle blocks smaller writes submitted after it. The project advises keeping transactions small and loading very large data during low interactive load. The project also says Blaze scales horizontally through its distributed storage variant, which uses Kafka as the transaction log. If your workload is many small writes from several applications, measure it against your own transaction sizes before choosing Blaze. HAPI FHIR documents support for DSTU2, DSTU3, R4, R4B and R5, which gives you more version coverage for mixed integration estates.

How does a CQL-heavy cohort or measure project change the effort?

Blaze is designed for this case. It includes an internal CQL evaluation engine and supports $cql, $evaluate-measure, $everything, $validate-code and $expand, with terminology services for LOINC and SNOMED CT. For cohort and measure work, that reduces the number of separate components you must integrate. Effort still depends on the number of libraries and measures, the value sets you must source and validate, and the clinical review of measure output. The supplied facts do not establish whether HAPI FHIR provides an equivalent CQL engine, so confirm that against HAPI's current documentation before you compare effort. Ask any implementation partner to quote per measure library and per terminology source, with the review steps written into scope.

Is switching from HAPI FHIR to Blaze later expensive?

The FHIR REST interface is the most portable layer, since both servers expose FHIR APIs, but the rest of the stack is not. HAPI stores data through JPA in a relational database, while Blaze keeps indices in embedded RocksDB and writes a transaction log to RocksDB or Kafka. A move therefore means exporting and reimporting data, then rebuilding authentication, because HAPI uses interceptors and Blaze uses Keycloak. Custom operations, search parameters and any partitioning design also need rework. The supplied facts do not describe a bulk migration tool for either server, so run a test migration with your real data volume and measure downtime. Budget for client retesting, identity rework and operator training as well.

What does a DeployOpen engagement require from the client?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Your team typically supplies access to the target environment, the identity provider and clinical requirements, representative data for load testing, and named owners who make decisions. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Ongoing support, upgrades and continuous testing are available as retainers.

How DeployOpen helps choose and implement a FHIR server

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the HAPI FHIR or Blaze decision is tested against your workloads before any build starts. The work runs as a written, fixed-scope engagement, with ongoing support available as a retainer.

How we scope

Written scope names the FHIR resources, write volumes and bundle patterns your systems will send.
We record which FHIR versions, terminology sets and cohort or measure operations your use case needs.
Authentication requirements, including the identity provider you already run, are documented before a server option is chosen.

How we build

We stand up the chosen server in your cloud account, data center or air-gapped network, not in a DeployOpen-hosted environment.
Storage and transaction-log design is configured for the write pattern agreed in scope, including how large bulk loads are scheduled.
Test plans cover conformance, load behavior under mixed transaction sizes and access control rules before go-live.

How we hand over

Deliverables include deployment documentation, configuration records and runbooks written for your own operations staff.
Compliance-relevant evidence, such as access logs and configuration baselines, is organized for your auditors, who issue any attestations.
Knowledge transfer sessions cover upgrades, backups and restore steps so your team can operate the server independently.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrade planning tracks new server releases against the versions and JDK or runtime requirements your environment already meets.
Retainer scope is agreed in writing, so response expectations and included testing are known before the engagement starts.

HAPI FHIR vs Blaze