---
{
  "title": "Performance à grande échelle : référence de base",
  "description": "Une note de référence pour notre série sur la performance à grande échelle : ce que nous mesurons en premier, pourquoi le point de départ est important, et comment nous assurons l'honnêteté du banc d'essai.",
  "date": "2026-06-29",
  "author": "Marat Surmashev",
  "reading-time": "6 min read",
  "tags": ["Database", "Infrastructure", "Aidbox", "Performance"]
}
---

## Pourquoi la référence de base est importante

Avant de comparer des serveurs FHIR sous charge, nous avons besoin d'un point de départ propre. La référence de base nous indique comment les systèmes se comportent sur une base de données vide (ou presque vide) et nous donne un repère pour tout ce qui suit — lorsque le volume de données et le trafic commencent à jouer un rôle.

Comme nous l'avons mentionné dans notre [article précédent](/articles/performance-at-scale), nous nous concentrons sur les charges de travail FHIR fondamentales : CRUD, traitement de Bundle et recherche. L'ensemble du banc d'essai est **libre (open source)** — le code source, le harnais de test et les résultats se trouvent tous dans [github.com/HealthSamurai/fhir-server-performance-benchmark](https://github.com/HealthSamurai/fhir-server-performance-benchmark), et l'exécution est relancée quotidiennement, de sorte que le [rapport interactif](https://healthsamurai.github.io/fhir-server-performance-benchmark/) (chaque graphique ainsi que les données brutes) reflète toujours les chiffres les plus récents. Les valeurs citées dans cet article proviennent de l'exécution du 28 juin 2026 ; le rapport en direct est la source de vérité.

Nous testons quatre serveurs FHIR : Aidbox, HAPI FHIR, Medplum et le Microsoft FHIR Server. Ils couvrent trois environnements d'exécution différents et deux bases de données différentes. Aidbox et HAPI tournent tous deux sur la JVM avec PostgreSQL ; Medplum fonctionne sur Node.js, également avec PostgreSQL ; et le Microsoft FHIR Server fonctionne sur .NET et fait figure d'exception côté stockage — il ne prend pas en charge PostgreSQL, donc nous l'exécutons sur SQL Server dans sa version la plus récente.

| Serveur | Base de code     | Environnement d'exécution | Base de données |
|---------|-----------------|--------------------------|-----------------|
| [Aidbox](https://www.health-samurai.io/fhir-server) | code source fermé | JVM (Clojure) | PostgreSQL |
| [HAPI FHIR](https://github.com/hapifhir/hapi-fhir) | code source ouvert | JVM (Java) | PostgreSQL |
| [Medplum](https://github.com/medplum/medplum) | code source ouvert | Node.js | PostgreSQL |
| [Microsoft FHIR Server](https://github.com/microsoft/fhir-server) | code source ouvert | .NET (C#) | SQL Server |

Le Microsoft FHIR Server est le plus récent ajout au banc d'essai, et les résultats ci-dessous l'incluent désormais aux côtés des trois serveurs fonctionnant sur PostgreSQL.


## Environnement de test

Nos tests s'exécutent sur une seule machine physique (bare-metal) dotée de 64 cœurs de processeur et de 500 Go de mémoire vive. L'ensemble de la pile est orchestré avec Docker Compose, et les ressources sont attribuées par conteneur afin que la comparaison reste équitable :

| Serveur | Image | CPU / RAM | Topologie |
|---------|-------|-----------|-----------|
| Aidbox | `healthsamurai/aidboxone:edge` | 8 vCPU / 24 Go | instance unique (JVM) |
| HAPI FHIR | `hapiproject/hapi:latest` | 8 vCPU / 24 Go | instance unique (JVM) |
| Medplum | `medplum/medplum-server:latest` | 1 vCPU / 3 Go chacun | 8 répliques (Node.js) |
| Microsoft FHIR Server | `mcr.microsoft.com/healthcareapis/r4-fhir-server:latest` | 8 vCPU / 24 Go | instance unique (.NET) |

Chaque serveur d'application dispose du même budget : 8 vCPU et 24 Go de RAM. Medplum y parvient différemment — son environnement d'exécution Node.js est monothread, si bien qu'un seul processus ne peut pas utiliser 8 cœurs ; il est déployé en 8 répliques de 1 vCPU / 3 Go chacune (8 vCPU et 24 Go au total) pour concourir à armes égales. Medplum s'appuie en outre sur Redis pour les sessions et la mise en cache, ce dont les autres n'ont pas besoin.

Pour les trois serveurs basés sur PostgreSQL, la couche base de données est **PostgreSQL 18** (8 vCPU / 30 Go), partagée au sein de la pile mais isolée selon un modèle « une base par serveur », de sorte que le stockage ou la charge de requêtes d'un serveur ne puissent pas affecter ceux d'un autre. Le Microsoft FHIR Server ne pouvant pas fonctionner sur PostgreSQL, il dispose de son propre **SQL Server 2022** (édition Développeur) dédié, avec le même budget de 8 vCPU / 30 Go — l'équivalent SQL Server du Postgres partagé. Comme les suites s'exécutent de façon séquentielle, un seul serveur d'application et sa base de données sont actifs à la fois. Tout fonctionne sur stockage SSD NVMe local afin d'éliminer la latence réseau des résultats et de maintenir le jeu de données au plus près du serveur.

Pour la génération de charge, nous utilisons [Grafana k6](https://k6.io/), qui exécute les scénarios en séquence (préchauffage → CRUD → importation → recherche). Pour les données synthétiques, nous utilisons [Synthea](https://github.com/synthetichealth/synthea), car il produit des profils de données de santé réalistes. L'utilisation du CPU, de la mémoire et des E/S par conteneur est collectée avec cAdvisor, tandis que les métriques internes des bases de données proviennent de postgres-exporter (pour les serveurs PostgreSQL) et de mssql-exporter (pour le SQL Server du Microsoft FHIR Server). L'ensemble est agrégé par Prometheus et visualisé dans Grafana — ce sont les mêmes métriques qui alimentent les graphiques ci-dessous. Tous les détails se trouvent sur la [page infrastructure](https://healthsamurai.github.io/fhir-server-performance-benchmark/infrastructure/) du rapport.

> **Une note sur l'équité.** Nous développons Aidbox, donc nous le connaissons naturellement mieux que les autres. Nous ne sommes *pas* des experts de HAPI FHIR, de Medplum ou du Microsoft FHIR Server, et il est tout à fait possible que notre configuration pour ces serveurs ne soit pas optimale. Notre objectif était à l'opposé du favoritisme : maximiser l'utilisation du matériel et accorder à chaque serveur les ressources les plus équitables possible. L'ensemble du dispositif est en code source ouvert précisément pour cette raison — si vous savez comment mieux régler l'un de ces serveurs, nous voulons vraiment le savoir. Ouvrez une issue ou une demande de tirage (pull request) dans [le dépôt du banc d'essai](https://github.com/HealthSamurai/fhir-server-performance-benchmark) et l'exécution quotidienne intégrera vos modifications.

## Suites et scénarios de test

Les tests de performance sont essentiels pour comprendre le comportement d'un système sous charge. Pour cette référence de base, nous exécutons trois suites, dans l'ordre :

1. **CRUD sur une base de données vide**
   - Mesurer les performances de création, de lecture, de mise à jour et de suppression sur une installation fraîche
2. **Importation par lot (1 000 patients)**
   - Effectuer une importation par lot de 1 000 dossiers patients synthétiques (Synthea) et mesurer le débit et le stockage
3. **Recherche**
   - Évaluer les performances des opérations de recherche sur le jeu de données importé

Cela nous donne un point de référence clair. Les jeux de données plus volumineux et la charge incrémentale — là où la dégradation en écriture et les requêtes complexes commencent à importer — font l'objet des prochains articles de la série.

## Performance CRUD de référence

La suite CRUD comprend des opérations séquentielles de création, de lecture, de mise à jour et de suppression sur neuf ressources FHIR différentes : Patient, Location, Practitioner, Organization, Encounter, MedicationRequest, Observation, Claim et ExplanationOfBenefit. La suite s'exécute avec 300 fils d'exécution (threads) simultanés pendant au maximum 5 minutes.

Nous établissons les métriques de référence avec le RPS moyen sur toutes les itérations.

__Débit moyen (RPS) pour l'ensemble des opérations CRUD (plus élevé est meilleur)__
![CRUD operations RPS on empty database](total_rps.svg)

| Serveur | Débit CRUD total (RPS) |
|---------|------------------------|
| Aidbox | 5 212 |
| HAPI | 3 058 |
| Medplum | 1 420 |
| Microsoft FHIR Server | 440 |

__Latence moyenne (99e percentile) par opération (plus bas est meilleur)__
![CRUD operations p99 latency by operation](describe_rps.svg)

| Opération | Aidbox | HAPI | Medplum | Microsoft |
|-----------|--------|------|---------|-----------|
| Création | 106 ms | 276 ms | 758 ms | 1 180 ms |
| Lecture | 91 ms | 225 ms | 404 ms | 379 ms |
| Mise à jour | 110 ms | 271 ms | 626 ms | 1 233 ms |
| Suppression | 93 ms | 239 ms | 647 ms | 1 064 ms |

D'après ces résultats, Aidbox offre environ 70 % de débit supplémentaire par rapport à HAPI et environ 3,7 fois plus que Medplum. Le Microsoft FHIR Server est loin derrière dans cette suite, à 440 RPS — soit plus d'un ordre de grandeur en dessous d'Aidbox. Sur la latence, Aidbox est environ 2,5 fois plus rapide que HAPI et 6 fois plus rapide que Medplum au 99e percentile. Le Microsoft FHIR Server est un cas intéressant : ses lectures sont rapides (379 ms p99, même devant Medplum), mais ses écritures sont les plus lentes du groupe (~1,2 s p99 en création et en mise à jour), ce qui fait chuter son débit global.

Un point à garder à l'esprit lors de la lecture de ces chiffres : l'écart de débit (≈70 % devant HAPI) est plus faible que l'écart de latence (≈2,5 fois). Sous forte concurrence, un serveur peut maintenir un débit agrégé élevé en traitant de nombreuses requêtes en parallèle, même si chaque requête individuelle est plus lente ; ainsi, la latence en queue de distribution et le RPS total ne bougent pas nécessairement ensemble — une comparaison sur un seul chiffre peut masquer ce qui importe réellement pour une charge de travail donnée.

__Latence moyenne pour toutes les opérations (99e percentile) en fonction de la taille de la ressource (plus bas est meilleur)__
![CRUD p99 latency by resource size](avg_latency_by_resource_size.svg)

Le graphique montre qu'Aidbox présente une légère corrélation entre la latence et la taille de la ressource, particulièrement visible lors du traitement des ressources Encounter, Patient et ExplanationOfBenefit. HAPI affiche une latence plus constante quelle que soit la taille des ressources, tandis que Medplum et le Microsoft FHIR Server sont uniformément élevés sur les écritures. On observe également un pic intéressant dans le traitement des ressources Patient par Medplum (son p99 de création monte à ~1,16 s, contre ~560–830 ms pour les autres ressources), ce qui laisse penser qu'un traitement supplémentaire s'effectue spécifiquement pour la ressource Patient.

## Traitement par lot

Pour tester les capacités de traitement par lot, nous avons utilisé un jeu de données de 1 000 dossiers patients synthétiques générés avec Synthea (environ 2 millions de ressources au total). Les Bundles FHIR générés varient en taille, allant de petits bundles d'environ 150 Ko à de grands bundles pouvant atteindre 120 Mo et jusqu'à 50 000 ressources dans un seul bundle. Chaque Bundle est de type `transaction`. Pour rendre le test plus réaliste et plus proche d'un usage réel, nous avons utilisé 20 fils d'exécution simultanés pour traiter ces bundles.

__Débit moyen (ressources par seconde) par serveur (plus élevé est meilleur)__
![1,000 synthetic patient records import throughput](1k_import_throughput.svg)

| Serveur | Débit d'importation (ressources/sec) |
|---------|--------------------------------------|
| Aidbox | 2 678 |
| HAPI | 2 214 |
| Medplum | 764 |
| Microsoft FHIR Server | 448 |

Pour le traitement par lot, Aidbox et HAPI se disputent la première place d'une exécution à l'autre — dans celle-ci, Aidbox est en tête, ingérant 2 678 ressources par seconde contre 2 214 pour HAPI (environ 21 % plus rapide). Medplum est nettement plus loin derrière les deux à 764 ressources par seconde, et le Microsoft FHIR Server est le plus lent à 448 ressources par seconde — environ 5 à 6 fois derrière les deux serveurs JVM.

__Taille de la base de données par serveur (plus bas est meilleur)__
![1,000 synthetic patient records import database size](1k_import_db_size.svg)

C'est sur le stockage que les quatre serveurs se différencient le plus, en deux catégories approximatives. Le Microsoft FHIR Server (4,24 Go) et Aidbox (6,83 Go) restent compacts ; Medplum (11,8 Go) et HAPI (22,6 Go) sont nettement plus volumineux — l'empreinte de HAPI représente environ 3,3 fois celle d'Aidbox. Les deux serveurs compacts y parviennent différemment : Aidbox en ne préconstruisant pas d'index, le Microsoft FHIR Server grâce à son entrepôt de données SQL Server — pourtant, comme nous l'avons vu plus haut, le serveur Microsoft le paie ailleurs, sous forme d'écritures et de recherches lentes. Nous revenons sur le compromis lié à l'indexation dans la conclusion.

## Suite de recherche

Effectuer un banc d'essai complet des fonctionnalités de recherche dans un serveur FHIR est un défi complexe pour plusieurs raisons :

1. FHIR dispose d'un vaste ensemble de paramètres de recherche, ce qui rend leur évaluation exhaustive très longue.
2. Il existe de nombreuses combinaisons de types de paramètres de recherche et de types de valeurs.
3. Divers modificateurs et préfixes peuvent être appliqués aux recherches.
4. Il existe des opérations complexes telles que les jointures (`_include`, `_revinclude`, `_has`, chaînées) et le tri.
5. Le nombre de combinaisons possibles de paramètres de recherche est considérable.

Puisqu'il est impraticable de tester toutes les combinaisons possibles de paramètres de recherche, nous nous concentrons sur les paramètres les plus couramment utilisés. Cela nous donne une solide compréhension de référence sur l'efficacité avec laquelle chaque serveur met en œuvre sa logique de recherche. Nous nous concentrons sur les paramètres de recherche FHIR R4 standard fréquemment utilisés en pratique et pour lesquels notre jeu de données synthétiques contient des données correspondantes, couvrant six familles : chaîne de caractères, date, référence, quantité, jeton (token) et paramètres composites FHIR.

Nous exécutons la suite avec 30 fils d'exécution simultanés (VUs k6) pendant 2 minutes, avec une taille de page fixe de 20 résultats (`_count=20`). Puisque les opérations de recherche peuvent retourner de grands ensembles de résultats, nous excluons le temps de transfert et d'analyse de la réponse des mesures en activant le paramètre k6 `discardResponseBodies: true` — nous nous concentrons uniquement sur le temps de réponse du serveur, et non sur la conformité FHIR. Toutes les familles de recherche s'exécutent en alternance au sein d'une même itération plutôt que de façon séquentielle, ce qui se rapproche davantage d'une utilisation réelle. Chaque famille lance également une valeur délibérément non correspondante (un identifiant, un code ou un nom inexistant) pour exercer le chemin de résultat vide, et les valeurs de référence sont prélevées en direct sur chaque serveur (identifiants de ressources réels) juste avant l'exécution.

Une mise en garde découle de la suppression des corps de réponse : nous mesurons le temps de réponse, pas la correction. Un serveur qui gère mal un type de requête — retournant une erreur, ou un résultat non filtré, rapidement — peut paraître artificiellement rapide. Nous signalons le seul cas que nous avons trouvé (la recherche composite de Medplum, ci-dessous), mais le même scepticisme s'applique à l'ensemble des résultats : considérez toute latence inhabituellement basse pour un serveur et un type donnés comme quelque chose à vérifier dans les résultats en direct plutôt qu'à accepter sans réserve.

Les paramètres que nous exercons :

| Type de recherche | Ressource | Paramètres |
|-------------------|-----------|------------|
| Chaîne de caractères | Patient | `name`, `address` (avec `:contains`) |
| Chaîne de caractères | Organization | `name` (avec `:contains`) |
| Date | Patient | `birthdate` |
| Date | Observation | `date` |
| Date | Encounter | `date` |
| Référence | Observation | `subject`, `encounter`, `performer` |
| Référence | Encounter | `subject`, `participant` |
| Référence | MedicationRequest | `subject`, `encounter`, `requester` |
| Quantité | Observation | `value-quantity`, `component-value-quantity`, `combo-value-quantity` |
| Jeton (token) | Observation | `category`, `code` |
| Jeton (token) | Encounter | `status`, `class` |
| Composite | Observation | `code-value-quantity`, `component-code-value-quantity`, `combo-code-value-quantity` |

Les recherches par date et par quantité font alterner les préfixes (`eq`, `lt`, `gt`, `ge`, `le` ; la date ajoute également `sa` et `eb`). Les recherches par chaîne de caractères utilisent le modificateur `:contains`. Les recherches par jeton (token) couvrent le format simple `[code]`, le format pleinement qualifié `[system]|[code]`, et les listes OR séparées par des virgules. Les recherches composites utilisent les paramètres composites FHIR avec le séparateur `$` (par exemple `code-value-quantity=8867-4$gt100`).

### Résultats de recherche

__Débit total de recherche (RPS, plus élevé est meilleur)__
![Search throughput by server](search_throughput.svg)

| Serveur | Débit de recherche (RPS) |
|---------|--------------------------|
| Aidbox | 3 404 |
| Medplum | 1 796 |
| HAPI | 1 005 |
| Microsoft FHIR Server | 261 |

__Latence P99 par type de recherche (ms, plus bas est meilleur)__
![Search p99 latency by type](search_latency.svg)

| Type de recherche | Aidbox | Medplum | HAPI | Microsoft |
|-------------------|--------|---------|------|-----------|
| Chaîne de caractères | 24 | 81 | 77 | 188 |
| Date | 26 | 82 | 121 | 271 |
| Référence | 24 | 83 | 96 | 167 |
| Jeton (token) | 32 | 82 | 97 | 197 |
| Quantité | 55 | 91 | 101 | 1 191 |
| Composite | 47 | — | 125 | 1 897 |

*Le graphique présente les quatre serveurs. Le p99 de quantité (~1,2 s) et de composite (~1,9 s) du Microsoft FHIR Server sort de l'échelle et écrase les trois serveurs PostgreSQL en de courts barres proches de la ligne de base — leurs valeurs exactes figurent dans le tableau ci-dessus. Medplum est absent du groupe composite car il ne prend pas en charge ce type de recherche (voir ci-dessous).*

L'ordre change par rapport au CRUD. Sur la recherche, Aidbox mène le débit à 3 404 RPS — environ 90 % de plus que Medplum (1 796 RPS) et environ 3,4 fois plus que HAPI (1 005 RPS). Le Microsoft FHIR Server est loin derrière à 261 RPS. Notamment, HAPI — qui était deuxième en CRUD — est le plus lent des trois serveurs PostgreSQL en recherche, tant sur le débit que sur la latence en queue de distribution.

Sur la latence, Aidbox affiche le p99 le plus bas pour chaque famille de recherche. Medplum se situe systématiquement au milieu — sauf pour le composite, qu'il ne prend pas en charge (voir la note ci-dessous). Parmi les serveurs Postgres, la latence de HAPI est la plus élevée, oscillant autour de 95–125 ms selon les familles. Le Microsoft FHIR Server est dans un régime totalement différent : acceptable pour les recherches par chaîne, date, référence et jeton (~170–270 ms), mais extrêmement lent sur les recherches par quantité (~1,2 s) et composites (~1,9 s) — ce qui plombe précisément son débit de recherche.

> **Medplum ne prend pas en charge la recherche composite.** La [documentation sur l'architecture de recherche](https://www.medplum.com/docs/contributing/search-architecture) de Medplum indique que le type de paramètre FHIR `composite` n'est pas pris en charge. Dans le banc d'essai, ces requêtes retournent sans effectuer la recherche, de sorte que toute latence ou tout débit qu'elles rapportent est un artefact plutôt qu'une mesure réelle — c'est pourquoi Medplum semblait « surpasser » tout le monde sur le composite dans les versions antérieures. Nous laissons donc la cellule composite de Medplum vide et l'excluons du graphique. La recherche par quantité, en revanche, *est* prise en charge par Medplum, donc ces chiffres sont valides.

Une note sur la portée : cette référence de base n'inclut pas le tri (`_sort`) ni les opérations de jointure (`_include`, `_revinclude`, `_has`, chaînées). Elles sont les plus intéressantes une fois que le volume de données augmente — sur un jeu de données de 1 000 patients, presque tout tient en mémoire — et nous les ajouterons sur des jeux de données plus volumineux dans un article ultérieur.

## Conclusion

Sur une référence de base propre, en grande partie résidente en mémoire, le classement se présente ainsi — il varie quelque peu d'une exécution quotidienne à l'autre, il faut donc le lire comme un instantané, non comme un verdict définitif :

- **CRUD** — Aidbox mène sur le débit (5 212 RPS) devant HAPI (3 058) et Medplum (1 420), avec le meilleur p99 sur chaque opération (~100 ms contre ~250 ms pour HAPI et ~610 ms pour Medplum). Le Microsoft FHIR Server est à la traîne à 440 RPS, avec des lectures rapides mais une latence en écriture de ~1,2 s.
- **Importation par lot** — Aidbox mène l'ingestion dans cette exécution (2 678 contre 2 214 ressources/sec pour HAPI) ; Medplum est loin derrière (764), et le Microsoft FHIR Server est le plus lent (448).
- **Recherche** — Aidbox mène à la fois sur le débit (3 404 RPS) et sur la latence par requête ; HAPI tombe au dernier rang parmi les serveurs Postgres, et le Microsoft FHIR Server est loin derrière sur le débit (261 RPS), plombé par des requêtes de quantité et composites très lentes.
- **Stockage** — deux catégories : le Microsoft FHIR Server (4,24 Go) et Aidbox (6,83 Go) sont compacts, tandis que Medplum (11,8 Go) et HAPI (22,6 Go) sont plus volumineux — l'empreinte de HAPI représente environ 3,3 fois celle d'Aidbox.

### Stratégie d'indexation : un compromis que cette référence de base ne mesure qu'à moitié

Les chiffres de stockage et d'importation découlent directement de la façon dont chaque serveur stocke et indexe les données — et ce choix est un compromis, non un verdict.

HAPI, Medplum et le Microsoft FHIR Server préconstruisent des index sur les champs consultables au moment de l'écriture des données. Cela coûte en débit d'écriture, et pour HAPI et Medplum, cela coûte en stockage (les 12–23 Go mentionnés plus haut). Le Microsoft FHIR Server montre que le coût de stockage n'est pas inévitable — il préconstruit des index et se maintient tout de même à 4,24 Go — mais il le paie lourdement en latence d'écriture.

Aidbox adopte la configuration par défaut opposée, et cela joue dans les deux sens. Il est livré **sans aucun index de recherche** — ce qui rend ses importations rapides et son empreinte réduite, mais cela signifie également qu'une requête non indexée retombe sur un balayage séquentiel, et que la responsabilité de l'indexation vous revient. Ce n'est pas une tâche triviale : vous devez savoir quels paramètres de recherche votre charge de travail utilise réellement, et une indexation excessive fait réapparaître précisément les coûts d'écriture et de stockage que nous venons de décrire. Ce qu'Aidbox offre à la place des index préconstruits, c'est la boîte à outils pour le faire délibérément — analytique des requêtes, statistiques sur les paramètres de recherche réellement utilisés, et recommandations d'index dérivées du trafic réel. Bien utilisé, cela vous permet d'indexer précisément pour votre charge de travail et d'obtenir à la fois des opérations rapides et un jeu de données très compact et efficacement stocké ; utilisé sans précaution, vous obtenez un serveur sans index. C'est une configuration par défaut plus puissante entre des mains expertes et un bord plus tranchant entre des mains inexpérimentées.

La mise en garde importante — et la raison pour laquelle il faut lire les chiffres de recherche ci-dessus avec attention — est que la préconstruction d'index apporte quelque chose : des performances de requête prévisibles à mesure que les données augmentent. Un jeu de données de 1 000 patients qui tient confortablement en mémoire est précisément le cas où ce bénéfice n'apparaît pas, de sorte que cette référence de base favorise structurellement la configuration par défaut sans index sur la recherche. Si cet avantage se maintient à mesure que les données augmentent — et si la dégradation au moment de l'écriture, et pas seulement la vitesse brute, commence à dominer — c'est exactement ce que le prochain article est conçu pour mesurer.

## La suite de la série

Voici le point de départ. Dans les prochains articles, nous passerons de la référence de base à des charges de travail plus lourdes — des jeux de données plus volumineux et une charge incrémentale — pour mesurer comment la vitesse d'importation se dégrade à mesure que les données s'accumulent, comment le CRUD et la recherche complexe (tri et jointures) se comportent sur une base de données pleine, et comment l'écart de stockage se projette à des volumes de données réalistes.

*Suivez-nous sur [LinkedIn](https://www.linkedin.com/company/health-samurai) pour la prochaine mise à jour du banc d'essai.*