Durante años, en demasiadas conversaciones de arquitectura se instaló una idea cómoda: que las bases de datos SQL “no escalan” y que, llegado cierto tamaño, el destino natural es abandonar el modelo relacional. En la práctica, lo que se rompe antes no suele ser SQL, sino la disciplina operativa alrededor de la base de datos: el diseño de esquemas, la higiene de consultas, los límites de conexión, la gestión de réplicas, los planes de backup y restauración, y la forma de absorber picos sin convertirlos en incidentes.
Los casos de referencia más útiles para un administrador de sistemas no son los que presumen de exotismo, sino los que muestran patrones repetibles. Shopify, por ejemplo, describe cómo mantiene su “monolito distribuido” sobre MySQL, con una arquitectura fragmentada (sharded) y orientada a escalar bajo picos como Black Friday / Cyber Monday: cientos de shards, un escritor por shard y múltiples réplicas para lectura y resiliencia, desplegados en miles de máquinas virtuales para sostener crecimiento y campañas.
En paralelo, Meta ha mantenido durante años un enfoque muy pragmático: MySQL en el centro, y cambios selectivos donde duele. Su fork público incluye MyRocks, un motor de almacenamiento basado en RocksDB orientado a mejorar eficiencia (especialmente en cargas intensivas de escritura o con presión de almacenamiento).
Y, para quienes asocian “escalar” a “distribuir”, el ecosistema también ofrece caminos SQL-first: Vitess, hoy bajo el paraguas de la CNCF, nació para escalar MySQL horizontalmente (con ideas como sharding, enrutamiento y operación a gran escala) y se popularizó precisamente por resolver ese dolor en entornos de gran volumen.
Incluso en el mundo de los proyectos “menos mediáticos”, pero con una exigencia operativa brutal, la lección se repite: Wikimedia documenta su uso de MariaDB en producción y el conjunto de herramientas y prácticas asociadas a su operación.
La conclusión para un medio de administradores de sistemas es menos filosófica y más accionable: SQL escala si se opera bien. Y operar bien no es una frase motivacional; es una lista de controles y decisiones que se pueden auditar.
Lo que suele escalar primero: hábitos, no tecnología
En producción, el salto de “va bien” a “se cae” rara vez lo provoca el motor SQL por sí solo. Los detonantes típicos son conocidos:
- Explosión de conexiones (pools mal dimensionados, timeouts agresivos, reintentos en cascada).
- Consultas que crecen sin control (filtros sin índice, joins costosos, patrones N+1).
- Hotspots (una tabla “central” o un conjunto de filas que concentran escrituras).
- Backups que no restauran (copias que existen, pero sin pruebas de recuperación).
- Replicación sin observabilidad (lag oculto, promoción manual improvisada en incidentes).
Por eso, cuando se habla de “SQL vs NoSQL”, a un sysadmin le conviene reformular la pregunta: ¿qué patrón necesito para mi SLO y mi operativa?
Tabla comparativa: patrones SQL que sí funcionan en entornos exigentes
| Necesidad operativa | Patrón recomendado | Encaje típico | Ventajas para sysadmin | Riesgos/Costes |
|---|---|---|---|---|
| Más lecturas sin tocar la app | Réplicas de lectura + separación RW/RO | Analítica ligera, catálogos, “feeds” | Reduce carga del primario; escalado progresivo | Lag de replicación; lecturas inconsistentes si no se diseña bien |
| Picos previsibles (campañas) | Capacity planning + escalado temporal + cachés | Ecommerce, media, SaaS | Control del riesgo; runbooks claros | Coste en infraestructura si se sobredimensiona |
| Crecimiento sostenido de datos/IO | Particionado + archivado | Logs, eventos, históricos | Mantiene tablas “vivas” pequeñas; facilita mantenimiento | Complejidad en queries y mantenimiento de particiones |
| Límite de escritura en un solo primario | Sharding por clave de negocio | Multi-tenant, grandes catálogos | Paraleliza escrituras; reduce hotspots | Complejidad en transacciones cross-shard y reporting global |
| Operación a escala (muchos shards) | Capa de orquestación (p. ej., Vitess) | Plataformas de gran volumen | Estandariza operación y routing; automatiza parte del trabajo | Curva de aprendizaje; nuevas piezas críticas |
| Coste/licencias y compatibilidad MySQL | MariaDB (según caso) | Entornos compatibles con MySQL | Alternativa con ecosistema amplio; opciones de clustering | Divergencias de compatibilidad; decisión de estándar interno |
Qué copiar (de verdad) de los grandes
1) Separar rendimiento de “heroísmo”.
Shopify no plantea su base de datos como un tótem, sino como un sistema con piezas repetibles: shards, roles claros (writer/replicas) y una estrategia que se tensiona en campañas. En producción, eso se traduce en runbooks, pruebas y automatización: lo que evita que la escalabilidad dependa del “sysadmin que lo sabe todo”.
2) Cambiar solo lo imprescindible.
MyRocks es un ejemplo de pragmatismo: no es “reinventar la base de datos”, sino ajustar el motor de almacenamiento para mejorar un cuello concreto, manteniendo el modelo SQL.
3) Operar pensando en el peor día, no en el promedio.
El valor de una arquitectura no se mide el martes tranquilo; se mide el día que el tráfico se multiplica y el negocio no acepta degradación. En ese escenario, el sysadmin necesita tres cosas: observabilidad (lag, QPS, latencias, locks), controles de admisión (rate limiting, colas, circuit breakers) y restauraciones ensayadas.
Un apunte sobre cifras “mágicas”
A menudo circulan métricas de “millones de consultas por segundo” asociadas a grandes plataformas. Son útiles como señal de orden de magnitud, pero peligrosas como objetivo: el número depende de qué se cuenta como consulta, del mix lectura/escritura, del caching y de cómo se instrumenta. Para un entorno real, la métrica que manda es otra: latencia p95/p99 bajo carga, tiempo de recuperación, y capacidad de mantener el servicio estable durante cambios (migraciones, failovers, reindexados).
Preguntas frecuentes
¿Qué señales indican que una base de datos SQL está llegando a su límite operativo?
Aumento sostenido de latencias p95/p99, saturación de CPU o IO, crecimiento del lag de replicación, locks frecuentes, colas de conexiones y degradación en ventanas de mantenimiento (backups, reindexados).
¿Cuándo tiene sentido plantear sharding en MySQL o MariaDB?
Cuando la escritura en un único primario se convierte en cuello estructural o aparecen hotspots imposibles de resolver con índices, particionado, caché y tuning. Suele encajar bien en arquitecturas multi-tenant con una clave natural de fragmentación.
¿Vitess sustituye a MySQL?
No: Vitess se sitúa como una capa para operar y escalar MySQL de forma distribuida (sharding, routing y operación a gran escala), manteniendo el backend MySQL como motor.
¿MariaDB es una alternativa “drop-in” a MySQL 8 en producción?
Depende del uso (SQL, motores, features, tooling). Puede ser viable en muchos escenarios, pero conviene validar compatibilidad real, comportamiento de replicación, features específicas y el estándar interno de operación; Wikimedia documenta su operación con MariaDB como referencia de prácticas y tooling.
Fuente: SQL a gran escala
