Les bases de données relationnelles restent le socle transactionnel de la majorité des systèmes d’information en production. Leur modèle tabulaire, normalisé autour de SQL et des propriétés ACID, garantit une cohérence que peu d’alternatives égalent sur les charges transactionnelles classiques. Nous observons toutefois que les limites historiques du modèle se déplacent : certaines tombent grâce aux évolutions récentes des SGBDR, d’autres persistent et orientent le choix vers des architectures complémentaires.
Verrouillage de schéma et rigidité structurelle : un frein souvent surestimé
Le reproche le plus fréquent adressé aux bases relationnelles concerne la rigidité du schéma. Toute modification de structure (ajout de colonne, changement de type, suppression d’une contrainte) impose une migration, parfois coûteuse sur des tables volumineuses.
A lire également : Qu'est-ce que la classe 10 des logiciels libres ?
Cette contrainte est réelle en exploitation, mais elle constitue aussi un filet de sécurité. Un schéma strict empêche l’insertion de données incohérentes à la source, là où une base documentaire reporte le contrôle sur la couche applicative. Sur des systèmes critiques (transactions financières, gestion de stock, dossiers patients), le schéma rigide protège l’intégrité mieux que la flexibilité.
Les SGBDR modernes atténuent par ailleurs cette rigidité. PostgreSQL propose depuis plusieurs versions le type JSONB, qui permet de stocker et d’indexer des documents semi-structurés à l’intérieur d’une table relationnelle. La fonction JSON_TABLE, ajoutée dans PostgreSQL 18, transforme des documents JSON en lignes relationnelles exploitables par des requêtes SQL standard. Nous recommandons d’évaluer ce mécanisme avant de basculer vers une base documentaire pour le seul motif de la flexibilité du schéma.
A voir aussi : Quels sont les 10 logiciels d'application ?
Scalabilité horizontale des bases relationnelles : ce qui a changé
L’argument historique contre les SGBDR en environnement distribué tient en une phrase : le modèle relationnel ne se partitionne pas facilement sur plusieurs nœuds. Le sharding manuel complexifie les jointures, et la réplication synchrone dégrade la latence d’écriture.
Cette limite reste pertinente, mais les offres managées récentes la réduisent significativement. Les « elastic clusters » fondés sur Citus, disponibles notamment sur les instances PostgreSQL managées d’Azure, combinent le moteur relationnel avec un sharding transparent. Le partitionnement est géré côté infrastructure, pas côté applicatif.
Ce que le sharding distribué ne résout pas
Les gains de performance de ces architectures ciblent principalement les lectures. Les goulets d’étranglement liés aux écritures intensives, au WAL (Write-Ahead Log) ou aux checkpoints restent présents. Un profil de charge dominé par les écritures concurrentes (ingestion IoT, logs massifs) tire peu de bénéfice de ces clusters élastiques.
Le choix entre une base relationnelle distribuée et une base NoSQL dépend donc du ratio lecture/écriture et de la tolérance à la cohérence éventuelle. Voici les critères que nous utilisons pour arbitrer :
- Charge majoritairement en lecture avec jointures complexes : le SGBDR distribué reste pertinent, les requêtes SQL sont conservées sans réécriture
- Ingestion massive en écriture avec peu de jointures : une base clé-valeur ou orientée colonnes sera plus performante
- Données semi-structurées avec besoin ponctuel de relations : PostgreSQL avec JSONB et JSON_TABLE couvre souvent le besoin sans changer de moteur
- Exigence ACID stricte sur chaque transaction : le modèle relationnel reste le seul à offrir cette garantie nativement sur l’ensemble du jeu de données
Portabilité et dépendances propriétaires des SGBDR
Un avantage souvent cité des bases relationnelles est la standardisation de SQL. En théorie, migrer d’un SGBDR à un autre se limite à adapter quelques fonctions spécifiques. En pratique, la portabilité dépend autant des extensions propriétaires que du SQL lui-même.
Les procédures stockées, les types de données spécifiques (geometry dans PostGIS, HierarchyID dans SQL Server), les mécanismes de réplication et les formats d’export créent un verrouillage technique progressif. Une application conçue autour des fonctions avancées d’Oracle ou de SQL Server ne migre pas vers PostgreSQL sans réécriture significative.
Contraintes réglementaires sur la portabilité des données
Le Data Act européen, dont les règles d’accès aux données sont entrées en application, impose des exigences de portabilité aux fournisseurs de services cloud. Cela concerne directement les bases relationnelles managées : les formats d’export, les API d’extraction et les coûts de migration deviennent des critères de conformité, pas seulement des critères techniques.
Nous recommandons d’intégrer cette dimension dès le choix initial du SGBDR. Privilégier un moteur open source réduit le risque de verrouillage à long terme, tant sur le plan technique que réglementaire.
Performances SQL sur les charges analytiques lourdes
Les bases relationnelles excellent sur les requêtes transactionnelles courtes (OLTP). Sur les charges analytiques (OLAP), agrégations massives, scans de tables entières, corrélations multi-tables, le modèle ligne par ligne montre ses limites face aux bases orientées colonnes.
Des systèmes hybrides tentent de combiner OLTP et OLAP dans un même moteur. Cette approche, parfois qualifiée de HTAP (Hybrid Transactional/Analytical Processing), évite de maintenir un pipeline ETL séparé entre la base transactionnelle et l’entrepôt analytique. Le compromis porte sur la latence : un moteur HTAP n’égale pas un entrepôt dédié sur les agrégations massives, mais il simplifie l’architecture pour les entreprises dont le volume analytique reste modéré.
Pour les systèmes de gestion qui traitent des transactions courantes tout en produisant des tableaux de bord opérationnels, un SGBDR bien dimensionné avec des vues matérialisées et un partitionnement adapté couvre le besoin sans infrastructure supplémentaire.
Quand ne pas choisir une base relationnelle
Le modèle relationnel n’est pas adapté à tous les cas d’usage. Trois situations justifient clairement une alternative :
- Données fortement connectées avec traversées de graphe (réseaux sociaux, détection de fraude) : une base orientée graphe réduit la complexité des requêtes récursives de plusieurs ordres de grandeur par rapport aux jointures SQL imbriquées
- Stockage de documents hétérogènes sans schéma prévisible (catalogues produits multi-fournisseurs, contenus éditoriaux) : une base documentaire évite les migrations de schéma répétées
- Flux temps réel à très haute vélocité d’écriture (télémétrie, logs applicatifs) : les bases orientées séries temporelles ou clé-valeur absorbent ces charges avec une latence d’écriture inférieure
Le choix d’un SGBDR pour un nouveau projet repose sur une analyse du profil de charge, pas sur une préférence technologique. Les bases relationnelles couvrent la majorité des besoins transactionnels structurés, et leurs évolutions récentes (sharding distribué, support JSON natif, moteurs HTAP) élargissent leur périmètre. Elles restent en revanche un mauvais choix quand la structure des données ou le débit d’écriture sort du cadre tabulaire normalisé.
