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.

Group Feature Aidbox Google Cloud Healthcare API Comment
Core FHIR versions STU3, R4, R5, R6 DSTU2, STU3, R4, R5 Google has broader version coverage than most managed services
Core GraphQL Supported No first-class GraphQL layer Aidbox exposes GraphQL as a product capability
Core Direct SQL access Supported Not supported Major Aidbox differentiator
Core SQL on FHIR Supported Not supported Google uses Pub/Sub and BigQuery instead
FHIR conformance Implementation guides Built-in artifact registry, custom IGs Supported IG enablement and IG import from Cloud Storage Aidbox is deeper as a FHIR platform
FHIR conformance User-defined search parameters Supported Supported in v1beta1
Customization Custom resources Supported via StructureDefinition No custom resource model Major Aidbox differentiator
Customization Access policies Built-in platform capability IAM/SMART-based access model Aidbox exposes authorization inside the platform
Security SMART on FHIR Supported Supported
Security Multitenancy Platform-level multitenancy Project/dataset/store + IAM boundaries Different tenancy model
Messaging & events FHIR subscriptions Supported Pub/Sub notifications instead of native FHIR Subscription replacement Different eventing model
Messaging & events Event destinations BigQuery, ClickHouse, Pub/Sub, Kafka, RabbitMQ, NATS, EventBridge, SNS Pub/Sub Aidbox has broader downstream routing
Terminology Terminology server Local / hybrid / remote modes More limited terminology surface Aidbox treats terminology as a first-class module
Analytics & AI Downstream analytics integrations SQL on FHIR/direct SQL + subscriptions Pub/Sub + near real-time BigQuery streaming Both are analytics-oriented, but with different architecture
Data modalities HL7v2 Supported Supported GHA treats HL7v2 as a first-class managed modality
Data modalities X12 Supported Not part of the core product surface Aidbox supports X12 flows such as 270/271 and 837
Data modalities C-CDA Supported via bidirectional converter Not part of the core product surface Aidbox supports both C-CDA to FHIR and FHIR to C-CDA
Data modalities DICOM Not a core platform modality Supported Major GHA advantage
Data modalities De-identification Supported in SQL on FHIR engine Supported GHA exposes de-identification as a managed API
Deployment Self-hosted / controlled deployment Supported No, managed Google Cloud service Major 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