---
{
  "title": "Performance at Scale: Benchmarking von FHIR-Servern unter realen Lastbedingungen",
  "description": "Wir führen Benchmarks für gängige Open-Source-FHIR-Server und Aidbox durch – über CRUD-, Batch-Verarbeitungs- und Such-Workloads. Was wir testen und warum.",
  "date": "2026-04-08",
  "author": "Marat Surmashev",
  "reading-time": "5 min read",
  "tags": ["Database", "Infrastructure", "Aidbox"]
}
---

## Warum Performance entscheidend ist

Performance wirkt sich direkt auf die Nutzererfahrung und die Betriebskosten aus. Endnutzer benötigen während ihrer Gesundheitsversorgung schnellen Zugriff auf Daten – jede Millisekunde Verzögerung summiert sich über Tausende täglicher Interaktionen und beeinflusst die klinische Effizienz sowie die Patientenergebnisse. Über die Nutzererfahrung hinaus bestimmt Performance die Infrastrukturkosten: Datenbankgröße, Backup-Umfang, Rechenressourcen und Wartungsaufwand skalieren alle mit dem Datenvolumen.

Bei der Wahl eines FHIR-Servers ist Performance einer der wichtigsten Faktoren. Jedes System, das auf FHIR aufbaut – EHR/PHR, CDR-Lösungen, Analyseplattformen – hat unterschiedliche Workload-Muster und erfordert unterschiedliche Performance-Eigenschaften. Für einen generischen FHIR-Server sind jedoch drei zentrale Workloads universell:

- **CRUD** – Erstellen, Lesen, Aktualisieren und Löschen einzelner Ressourcen
- **Batch-Verarbeitung** – Massenimport, Datenaustausch und Integrationsszenarien
- **Suche** – Abfragen von Ressourcen anhand verschiedener Parameter

FHIR-Batch-Verarbeitungs-APIs werden häufig für Datenaustausch und Integration eingesetzt – beispielsweise beim Migrieren von Daten aus Legacy-Systemen in einen FHIR-Server. CRUD- und Suchoperationen treiben OLTP-Workloads an: den Aufbau von EHR/PHR-Systemen, patientenorientierten Anwendungen und klinischen Entscheidungsunterstützungswerkzeugen.

![Latency comparison](latency2.png)

## Was wir benchmarken

Wir werden mehrere gängige Open-Source-FHIR-Server benchmarken und sie mit Aidbox vergleichen.

Für jeden Server messen wir:

- **Durchsatz** – Operationen pro Sekunde unter anhaltender Last
- **Latenz** – p99-Antwortzeiten
- **Ressourcenverbrauch** – CPU-, Arbeitsspeicher- und I/O-Auslastung
- **Speicherplatzbedarf** – wie viel Speicher jeder Server für denselben Datensatz benötigt

Wir haben die Testsuite so konzipiert, dass das Performance-Verhalten sowohl auf einer leeren Datenbank als auch nach einem erheblichen Datenvolumen erfasst wird. Dies ist entscheidend – viele Server liefern bei kleinen Datensätzen gute Ergebnisse, degradieren jedoch mit wachsendem Datenbestand.

### Stufe 1: Leere Datenbank

Ausgehend von einer Neuinstallation:

1. Basis-Performance der CRUD-Operationen messen
2. 1.000 synthetische Patientendatensätze per Batch importieren (generiert mit [Synthea](https://synthetichealth.github.io/synthea/))
3. Performance verschiedener Suchoperationen auswerten

Damit wird die Basislinie etabliert – das Best-Case-Szenario für jeden Server.

### Stufe 2: 100.000 Patienten laden

100.000 synthetische Patientendatensätze importieren und Folgendes messen:

- Gesamtdauer des Imports
- Datenbankgröße auf dem Datenträger
- Ressourcenverbrauch während des Imports

Dies simuliert ein realistisches mittelgroßes Deployment und zeigt, wie jeder Server mit anhaltend hohem Schreibdruck umgeht.

### Stufe 3: Inkrementelle Lasttests

Mit bereits 100.000 Patienten in der Datenbank:

1. CRUD-Operationen erneut ausführen – Vergleich mit der Basislinie der leeren Datenbank
2. Zusätzliche 1.000 Patientendatensätze auf den bestehenden 100.000 importieren
3. Suchoperationen erneut ausführen – messen, wie sich die Abfrage-Performance mit dem Datenvolumen verändert

Die Differenz zwischen Stufe 1 und Stufe 3 erzählt die eigentliche Geschichte: **Wie gut hält die Performance stand, wenn die Datenmenge wächst?**

## Bleiben Sie auf dem Laufenden

Wir werden alle Benchmarks, Testskripte und Rohergebnisse in kommenden Beiträgen veröffentlichen. Folgen Sie uns auf [LinkedIn](https://www.linkedin.com/company/health-samurai), um keine Updates zu verpassen.

---

*Haben Sie Fragen zur Performance von FHIR-Servern? [Kontaktieren Sie uns](/contacts) – wir optimieren Aidbox seit über einem Jahrzehnt für groß angelegte Deployments.*