Comparison · 2026-04

Aidbox vs
Google Cloud
Healthcare API.

One is a FHIR-native backend platform built around Postgres and direct SQL. The other is a managed cloud service tightly integrated with Pub/Sub, BigQuery, and Vertex AI.

01 · Architecture

Two fundamentally different platforms.

Aidbox

FHIR-native backend platform

Built around PostgreSQL, JSONB storage, direct SQL access, GraphQL, SQL on FHIR, custom resources, and self-hosted / on-prem deployment.

Beyond FHIR — also covers HL7 v2, X12, and bidirectional C-CDA ↔ FHIR conversion.

Google Cloud Healthcare API

Managed cloud service

Exposes FHIR, HL7v2, and DICOM APIs, plus de-identification and integrations with Pub/Sub, BigQuery, and Vertex AI.

Tight fit with the rest of the Google Cloud analytics and AI stack.

02 · Downstream analytics

Both are analytics-oriented — the pattern differs.

Aidbox

  • Direct PostgreSQL access and SQL on FHIR for analytics close to live transactional data
  • Subscriptions for near real-time delivery into BigQuery, ClickHouse, Pub/Sub, Kafka, RabbitMQ, NATS, AWS EventBridge, and AWS SNS

Google Cloud Healthcare API

  • Pub/Sub notifications for FHIR, HL7v2, and DICOM events
  • Near real-time BigQuery streaming for FHIR resource changes
  • Stronger fit for teams standardizing on Google Cloud analytics and AI services

03 · FHIR conformance

Where each product stands on the spec.

Aidbox

STU3, R4, R5, R6

Plus profiles, IGs, search parameters, terminology, SQL, and GraphQL. Stronger when the FHIR layer itself must be extended and used as part of the product architecture.

Google Cloud Healthcare API

DSTU2, STU3, R4, R5

FHIR stores with profile validation, implementation guides, referential integrity, and user-defined search parameters in v1beta1.

Known gaps: no _filter in R4, and limitations around some search parameters and canonical searches.

04 · Features

Feature matrix — filter by group.

GroupFeatureAidboxGoogle Cloud Healthcare APIComment
CoreFHIR versionsSTU3, R4, R5, R6DSTU2, STU3, R4, R5Google has broader version coverage than most managed services
CoreGraphQLSupportedNo first-class GraphQL layerAidbox exposes GraphQL as a product capability
CoreDirect SQL accessSupportedNot supportedMajor Aidbox differentiator
CoreSQL on FHIRSupportedNot supportedGoogle uses Pub/Sub and BigQuery instead
FHIR conformanceImplementation guidesBuilt-in artifact registry, custom IGsSupported IG enablement and IG import from Cloud StorageAidbox is deeper as a FHIR platform
FHIR conformanceUser-defined search parametersSupportedSupported in v1beta1
CustomizationCustom resourcesSupported via StructureDefinitionNo custom resource modelMajor Aidbox differentiator
CustomizationAccess policiesBuilt-in platform capabilityIAM/SMART-based access modelAidbox exposes authorization inside the platform
SecuritySMART on FHIRSupportedSupported
SecurityMultitenancyPlatform-level multitenancyProject/dataset/store + IAM boundariesDifferent tenancy model
Messaging & eventsFHIR subscriptionsSupportedPub/Sub notifications instead of native FHIR Subscription replacementDifferent eventing model
Messaging & eventsEvent destinationsBigQuery, ClickHouse, Pub/Sub, Kafka, RabbitMQ, NATS, EventBridge, SNSPub/SubAidbox has broader downstream routing
TerminologyTerminology serverLocal / hybrid / remote modesMore limited terminology surfaceAidbox treats terminology as a first-class module
Analytics & AIDownstream analytics integrationsSQL on FHIR/direct SQL + subscriptionsPub/Sub + near real-time BigQuery streamingBoth are analytics-oriented, but with different architecture
Data modalitiesHL7v2SupportedSupportedGHA treats HL7v2 as a first-class managed modality
Data modalitiesX12SupportedNot part of the core product surfaceAidbox supports X12 flows such as 270/271 and 837
Data modalitiesC-CDASupported via bidirectional converterNot part of the core product surfaceAidbox supports both C-CDA to FHIR and FHIR to C-CDA
Data modalitiesDICOMNot a core platform modalitySupportedMajor GHA advantage
Data modalitiesDe-identificationSupported in SQL on FHIR engineSupportedGHA exposes de-identification as a managed API
DeploymentSelf-hosted / controlled deploymentSupportedNo, managed Google Cloud serviceMajor operating model difference

05 · Performance

Not a direct benchmark — but architecturally different.

Google documents managed scalability, but does not publish enough latency or throughput data for a direct benchmark against Aidbox.

Architecturally, Aidbox is closer to operational SQL workloads; Google is closer to managed infrastructure and downstream pipelines.

06 · Pricing

Two different cost models.

Google Cloud Healthcare API

Per-request / usage-based

Main cost drivers: API requests, storage, notifications, ETL, de-identification, network usage.

As of 2026-04-21

  • $0.39 per 100,000 standard requests after the free tier
  • $0.29 per 1 million standard notifications
  • ~$0.19–$0.39 per GB-month for structured storage (region/tier dependent)
  • Streaming export and de-identification billed separately

Costs scale with workload.

Aidbox

Flat-fee license + infrastructure cost

Compared to GHA, the model is less self-serve, but more predictable for high-volume production workloads.

Tradeoff

Predictable cost ceiling. Costs don't scale per request — they scale with infrastructure footprint.

Summary

When each product fits.

Pick Aidbox when

  • FHIR must be extensible — custom resources, profiles, IGs as a product capability
  • Direct SQL, SQL on FHIR, GraphQL are part of the product surface
  • HL7 v2, X12, or C-CDA flows alongside FHIR
  • Self-hosted / on-prem deployment, predictable flat-fee pricing

Pick Google Cloud Healthcare API when

  • Team is already standardized on Google Cloud (BigQuery, Vertex, Pub/Sub)
  • DICOM is part of the modality mix
  • Managed-only operating model, usage-based pricing acceptable
  • De-identification as a managed API is a primary requirement
1/8