FHIR resources compress well on paper. Field names repeat, canonical URLs repeat, resource structures share vocabulary, and JSON as a format is verbose. Every FHIR server ships with some form of compression enabled and every storage plan quietly assumes the compression discount. The catch is that the discount has real limits, and plans that treat it as unbounded end up over-optimistic.
Naming the limits explicitly is the discipline that keeps the estimate honest. For related walkthroughs, the FHIR primer collection collects the surrounding material.
What FHIR JSON Actually Compresses Into
At the resource level, FHIR JSON typically compresses at a ratio of five to one under standard algorithms. A three-kilobyte Observation lands at around six hundred bytes compressed. A twenty-kilobyte Bundle can compress to three or four kilobytes.
The compression ratio is not uniform. Highly-structured resources with repeated field names compress well; resources with large free-text fields or attachments compress less. A pass through the site's FHIR storage bill projector reflects the effective compressed footprint per engine.
Where the Discount Runs Out
Compression works on redundancy. The moments the discount runs out are the moments the redundancy runs out:
- Attachments (inline base64) barely compress.
- Long free-text notes compress modestly.
- Encrypted fields, by design, do not compress.
- Structured resources with unique identifiers compress less than pattern-matching resources.
Deployments dominated by attachments should not budget for the same compression ratio as deployments dominated by structured Observations. For the attachment ambush shape, the FHIR storage costs you forgot to budget is the accompanying reference.
Deduplication Is a Different Lever
Deduplication looks for identical blocks across the archive and stores each block once. On FHIR archives it usually finds two categories: reference resources (CodeSystems, ValueSets, StructureDefinitions) that appear once per entry in many Bundles, and near-identical Bundle payloads generated by templated workflows.
The dedup ratio depends on the deployment. Highly-templated ingestion workflows can see thirty percent dedup savings. Deployments with unique per-patient data see less. For the resource-level footprint framing, per-resource storage footprint: what actually takes space covers the base numbers before compression and dedup.
The Interaction With History
Compression discounts on history are stronger than on current state because history holds many near-identical versions of the same resource. A resource updated five times with small changes produces highly compressible history rows.
Some FHIR servers use delta compression on history: store the first version fully and each subsequent version as a diff against the previous. Delta compression pushes the history-versus-current-state multiplier closer to one. Not every server supports it. Sizing plans should name whether the target server does.
The Encryption Trade
At-rest encryption is table stakes for regulated FHIR deployments. Encrypted blocks do not compress. Deployments that encrypt at the storage layer keep the compression discount by encrypting after compression. Deployments that encrypt at the FHIR layer often lose the compression discount entirely.
Naming the encryption placement in the sizing plan is important. The wrong placement can double the archive size for the same data.
Backups Also Compress
Backup software applies its own compression. The effective ratio compounds: a five-to-one FHIR compression combined with a two-to-one backup compression lands at ten-to-one for the backup archive. The catch is that overlapping compression rounds have diminishing returns; the actual number is usually less than the product.
Measure the actual backup archive size against the source. Estimates that assume multiplicative compression are usually optimistic by a factor of two.
Reporting Compressed and Raw Together
The sizing plan should report both raw and compressed footprints. Raw size is what the data would occupy without compression, and it is the number that grows with resource count. Compressed size is what actually consumes disk. For the up-front estimation framework, estimating storage before you commit to a FHIR platform is the accompanying reference.
Compression is a real discount. Treating it as unbounded is where sizing plans quietly drift into fiction.
Sources
- PostgreSQL canonical TOAST documentation applicable to FHIR - PostgreSQL canonical TOAST documentation applicable to FHIR JSONB compression