Depuis des années, l’idée selon laquelle « SQL ne scale pas » sert souvent de raccourci mental : lorsque le produit se développe, on suppose qu’il faudra « sortir » d’une base de données relationnelle pour adopter des alternatives conçues pour répartir données et trafic dès le départ. La nuance embarrassante est que cette prétendue limite s’effondre dès qu’on observe le fonctionnement de plusieurs des plateformes les plus exigeantes au monde.

La réalité est moins épique mais bien plus utile : faire évoluer SQL repose souvent sur l’architecture, l’exploitation et la discipline d’ingénierie, et non sur des « limitations intrinsèques » du modèle relationnel. En d’autres termes : si SQL sait répondre aux besoins des systèmes soumis à des pics de trafic extrêmes, il peut également – avec une forte probabilité – convenir à la majorité des produits qui ne frôlent pas ces conditions.

Shopify, l’e-commerce et les coulisses de MySQL

Dans le domaine du commerce en ligne, il y a un moment crucial où la théorie devient réalité : campagnes à fort trafic, incidents, dégradations maîtrisées, prises de décisions rapides. Shopify a partagé publiquement certains aspects de son approche technique autour de MySQL et d’infrastructure pour absorber ces pics, comme ProxySQL, qui gère les connexions et répartit le trafic entre les primaires et les réplicas en lecture. Leur expérience évoque même l’exploitation de miles d’instances de ProxySQL et de mécanismes pour appliquer des règles de routage ou de mitigation en toute sécurité opérationnelle lorsque le système est sous pression.

Inutile de faire de cela un « SQL triomphe » : l’essentiel est la leçon. Quand le trafic s’intensifie, la stratégie consiste souvent à déplacer les lectures vers des réplicas, contrôler l’accès, protéger le primaire et automatiser les changements, plutôt que de tout abandonner et jeter la base de données par-dessus bord.

Meta et MyRocks : when I/O and costs are the real challenge, not “SQL vs NoSQL”

Un autre exemple classique provient de Meta (Facebook), qui a travaillé avec MyRocks, un moteur de stockage pour MySQL axé sur l’optimisation de l’espace et des écritures via la famille de techniques LSM (notamment RocksDB). Le projet a été documenté et partagé en open source, avec des références techniques et des dépôts associés.

La leçon ici est quasi chirurgicale : à une certaine échelle, la discussion quitte le domaine « relationnel ou non » pour devenir le coût par téraoctet, l’amplification des écritures, les latences p99, la compression, et l’efficacité du stockage. SQL ne disparaît pas ; il s’adapte en profondeur.

YouTube et Vitess : le sharding n’est pas une religion, c’est une technique

Pour monter en charge horizontale, le concept qui revient le plus souvent est le sharding : diviser les données par une clé (utilisateur, tenant, région, etc.) pour répartir la charge. Dans l’écosystème MySQL, le cas le plus connu est Vitess, un projet né chez YouTube et aujourd’hui largement adopté, justement pour faire fonctionner MySQL à grande échelle avec sharding et couche d’orchestration.

Encore une fois, il ne s’agit pas uniquement de « utiliser Vitess » : l’enjeu est de comprendre que SQL peut évoluer horizontalement si la topologie (et l’application) sont conçues pour cela.

PostgreSQL aussi en première division : Instagram et la croissance « sans changer de base »

Le refrain « SQL ne scale pas » s’effondre également en regardant PostgreSQL. Il y a quelques années, Instagram expliquait comment Postgres restait leur « fondation solide » tout en croissant, grâce à des pratiques comme le partitionnement horizontal et l’optimisation (indices partiels, indices fonctionnels, etc.).

Cela invalide un autre mythe : que « Postgres est pour les moyens » et « MySQL pour le web ». En pratique, les deux peuvent gérer des charges énormes si leur conception et leur exploitation sont adaptées.

Plus d’exemples concrets : Pinterest et Airbnb dans l’univers MySQL

Dans l’ingénierie réelle, le débat ne tourne souvent pas autour de « quelle base de données choisir » mais plutôt de « comment réduire le risque aujourd’hui ». Pinterest a détaillé son usage de shards MySQL et de bonnes pratiques pour gérer l’échelle opérationnelle.
Airbnb, quant à lui, a partagé des cas où le comportement des réplicas MySQL et la latence associée sont aussi critiques que le schéma lui-même, montrant que la scalabilité dépend aussi de l’observabilité et du contrôle précis du système.

Et MariaDB : le « fork » devenu une alternative opérationnelle

Quand MariaDB apparaît en discussion, c’est souvent comme un « MySQL compatible ». En pratique, pour de nombreuses organisations, c’est une décision d’ordre opérationnel et stratégique. Un exemple souvent cité est l’utilisation de MariaDB dans l’écosystème Wikimedia, souvent évoqué comme un déploiement à grande échelle en référence publique.

Tableau comparatif : options SQL courantes pour évoluer

Le constat est clair : SQL peut évoluer, mais pas magiquement. Il évolue quand la conception l’inclut : séparation des lectures/écritures, clés de partition réalistes, coûts liés à l’opération distribuée, automatisation et observabilité.

Conclusion : le vrai débat ne concerne pas « SQL oui/non », mais « quelle architecture »

Pour la majorité des équipes, la décision la plus pragmatique consiste souvent à bien exploiter un SQL (MySQL/PostgreSQL/MariaDB) avec un bon design, réplicas, caches, limites et surveillance, et à ne passer à des architectures plus complexes qu’une fois que les données montrent qu’il faut évoluer.

Les enseignements de Shopify, Meta, YouTube ou Instagram ne sont pas qu’il existe une « base de données gagnante » : ce sont que les grands systèmes se construisent avec de l’ingénierie : topologies, proxies, sharding, optimisation, et opérations rigoureuses.

Questions fréquentes

Quand « primaires + réplicas » ne suffit-il plus en MySQL ou PostgreSQL ?
Quand le vrai goulet d’étranglement est en écriture ou en contention (verrous, lignes chaudes, index saturés), et que le partitionnement par domaine devient incontournable.

Vitess est-il réservé aux ultra-scalaires ?
Pas nécessairement, mais il représente une étape majeure : utile quand le sharding devient la norme opérationnelle, et non l’exception.

Quels types de produits tirent davantage parti de MyRocks ?
Les charges avec beaucoup d’écritures et de pression stockage (coût par téraoctet), où l’efficacité du moteur et des I/O conditionnent la viabilité économique.

MariaDB n’est-elle qu’un « remplaçant » de MySQL ?
Elle peut l’être dans des cas simples, mais dans des déploiements à grande échelle, la décision inclut souvent la compatibilité, la gouvernance du stack, le support et la stratégie plateforme.