FHIR server scale and performance challenges
summary
Claims that serving FHIR on terabytes at hundreds–thousands RPS is solvable by measurement, tuning and trade‑offs: use Prometheus/Grafana for metrics, run a 10 terabytes bench, profile PostgreSQL/JSONB layouts, and focus on percentiles not averages. Bulk import plus drop indexes and rebuild cuts ingestion from ~5 hours for 100k patients to minutes and reaches ~100 resources/sec; composite indexes and GIN vs B‑tree choices turn joins from seconds to milliseconds. Also use _total=false and query timeouts to avoid accidental denial of service.
AI-written summary · about
chapters (10)
- 0:00Introduction and context
- 1:11Performance as a rabbit hole
- 3:36Monitoring and observability
- 6:16Ingestion benchmarks
- 11:34Optimization strategies
- 16:10Search performance analysis
- 21:11Database internals
- 25:45Advanced tuning and trade-offs
- 31:27Conclusion and future plans
- 33:05Q&A session
related talks
26mExploring FHIR Performance Benchmarking
34mFHIR Projects
27mStorage and analytics
44mTransforming FHIR Data for horizontally scalable analytics
16mThe story of FHIR data exchange and storage combined
27mTales at Scale: Analytics at 1000 QPS and Beyond
38mScaling FHIR with microservices
29mSQL on FHIR 2.0