Durante años, la creencia de que “SQL no escala” ha servido como un atajo mental: cuando un producto crece, se asume que será necesario abandonar las bases de datos relacionales y adoptar alternativas diseñadas para distribuir datos y tráfico desde el inicio. Sin embargo, esta narrativa se descompone rápidamente al analizar cómo operan las plataformas más exigentes del mundo.
La realidad es menos épica, pero mucho más práctica: escala con SQL suele ser cuestión de arquitectura, operación y disciplina de ingeniería, no de “limitaciones intrínsecas” del modelo relacional. En otras palabras: si SQL funciona para manejar picos de tráfico extremos, probablemente también sea válido —con las adaptaciones correctas— para la mayoría de los productos que no enfrentan esas condiciones.
Shopify, el comercio electrónico y la infraestructura de MySQL
En el mundo del comercio electrónico, hay momentos en el año que separan la teoría de la práctica: campañas de alto tráfico, incidentes, degradaciones controladas y decisiones rápidas. Shopify ha compartido públicamente su enfoque técnico en torno a MySQL y componentes de infraestructura que ayudan a gestionar picos, como ProxySQL, un sistema que administra conexiones y distribuye tráfico entre primarios y réplicas de lectura. En su caso, incluso hablan de operar miles de instancias de ProxySQL y de mecanismos para aplicar reglas de enrutamiento o mitigación con seguridad operacional cuando el sistema está bajo presión.
No es necesario verlo como una competencia de “SQL gana o pierde”: la lección clave es otra. Cuando el tráfico se intensifica, la estrategia suele ser mover las lecturas a réplicas, gestionar el acceso, proteger el primario y automatizar los cambios. La solución no es desechar la base de datos.
Meta y MyRocks: cuando el desafío es I/O y coste, no “SQL versus NoSQL”
Otro ejemplo clásico es Meta (antes Facebook), que ha trabajado con MyRocks, un motor de almacenamiento para MySQL orientado a optimizar espacio y escrituras mediante técnicas LSM (como RocksDB). Este proyecto ha sido documentado y compartido públicamente, incluyendo referencias técnicas y repositorios asociados.
La enseñanza aquí es casi quirúrgica: a cierta escala, la discusión deja de ser “relacional o no relacional” para concentrarse en costos por terabyte, amplificación de escrituras, latencias p99, compactación y eficiencia del almacenamiento. SQL no desaparece; más bien, se ajusta a las nuevas realidades operativas.
YouTube y Vitess: el “sharding” no es una religión, sino una técnica
Para lograr escalabilidad horizontal, el concepto predominante es el particionado (sharding): dividir los datos por alguna clave (usuario, tenant, región, etc.) para distribuir la carga. En el ecosistema MySQL, el ejemplo más conocido es Vitess, un proyecto que nació en YouTube y que hoy en día es ampliamente adoptado para gestionar MySQL a gran escala mediante particionado y orquestación.
El objetivo no es simplemente “usar Vitess”, sino entender que SQL puede escalar horizontalmente si la topología (y la aplicación) están diseñadas con esa finalidad.
PostgreSQL también en primera división: Instagram y el crecimiento “sin cambiar de base”
La idea de que “SQL no escala” también se desmonta al analizar PostgreSQL. Hace años, Instagram explicó cómo Postgres continuó siendo su “base sólida” conforme crecían, implementando prácticas como el particionado horizontal y optimizaciones (índices parciales, índices funcionales y otras técnicas operativas).
Esto demuestra que otro mito se disipa: que “Postgres es solo para cargas medianas” y “MySQL para web”. En la práctica, ambos pueden sostener cargas muy altas cuando el diseño y la gestión son adecuados.
Más ejemplos prácticos: Pinterest y Airbnb en el mundo MySQL
En ingeniería real, a menudo el debate no trata sobre “qué base de datos elegir”, sino sobre “cómo reducir riesgos hoy”. Pinterest ha compartido su uso de shards de MySQL, junto con prácticas para gestionar la escala operativa en torno a esa estrategia.
Airbnb, por su parte, ha mostrado casos en los que el comportamiento de réplicas MySQL y las latencias relacionadas son tan críticos como la estructura de los esquemas, resaltando que la escalabilidad también es cuestión de observabilidad y control fino del sistema.
Y MariaDB: el “fork” que se convirtió en una alternativa operativa
Cuando se menciona MariaDB en la conversación, habitualmente se lo presenta como “compatibilidad con MySQL”. En la práctica, para muchas organizaciones representa una decisión operativa y de gestión tecnológica. Un ejemplo muy citado es su uso en el ecosistema Wikimedia, que suele citarse como referencia en despliegues a gran escala.
Tabla comparativa: opciones SQL comunes para escalar
| Opción | Cómo suele escalar | Puntos fuertes | Compromisos típicos | Ejemplos públicos (orientativos) |
|---|---|---|---|---|
| MySQL (clásico) | Primario + réplicas, cachés, particionado por aplicación | Madurez, buen tooling, rendimiento probado en web | Escrituras concentradas en primario si no se parte | Shopify (MySQL + ProxySQL), Pinterest |
| MySQL + ProxySQL | Gestión de conexiones, enrutado a réplicas, mitigación en incidentes | Reduce presión en la base, mejora respuesta operativa | Añade capa adicional (proxy) y complejidad | Shopify |
| MySQL + Vitess | Sharding asistido + orquestación | Escalado horizontal más sistemático | Cambios en modelo operativo y, a veces, en aplicación | Origen en YouTube; adopción amplia |
| MySQL + MyRocks | Optimiza almacenamiento y escrituras manteniendo SQL | Reducción de costos y mejora en eficiencia I/O | Trade-offs del método LSM (compactación, tuning) | Meta (Facebook) |
| PostgreSQL | Réplicas, particionado, optimización avanzada de consultas | Poder del SQL, extensibilidad, robustez | Escalar horizontalmente requiere buen diseño | |
| MariaDB | Similar a MySQL (réplicas, clústeres según diseño) | Compatibilidad y flexibilidad en despliegues | Variaciones según versión y compatibilidad con features | Wikimedia (referencia de despliegue) |
| Distributed SQL (Spanner/Cockroach/Yugabyte) | Distribución nativa con fuerte consistencia (según sistema) | Menos dependencia de “pegamento” externo para repartir datos | Alta complejidad y costo; depende mucho del caso | (Varía por plataforma y proveedor) |
La conclusión clara de esta comparación es que SQL puede escalar, pero no “por arte de magia”. La escala se logra cuando se diseña con esa finalidad: separando lecturas y escrituras, eligiendo claves de particionado realistas, asumiendo los costes de operaciones distribuidas y construyendo automatización y observabilidad.
Conclusión: el debate útil no es “SQL sí/no”, sino “¿qué arquitectura necesito?”
Para la mayoría de los equipos, la decisión más pragmática es: optimizar un SQL (MySQL/PostgreSQL/MariaDB) con buen diseño, réplicas, cachés, límites y observabilidad, y solo migrar a arquitecturas más complejas cuando los datos demuestren de forma concreta que es necesario.
Las lecciones de Shopify, Meta, YouTube o Instagram no indican que exista una base de datos “ganadora”. La clave está en que los sistemas grandes se construyen con ingeniería: topologías, proxies, particionado, optimización y operaciones rigurosas.
Preguntas frecuentes
¿Cuándo deja de ser suficiente “primario + réplicas” en MySQL o PostgreSQL?
Cuando la verdadera limitación está en las escrituras o en la contención (locks, filas calientes, índices que no soportan carga), y el particionado por dominio empieza a ser imprescindible.
¿Vitess es solo para “hiperescalares”?
No necesariamente, pero implica un salto: funciona muy bien cuando el sharding deja de ser una excepción y pasa a ser una práctica habitual en la operación.
¿Qué tipo de producto se beneficia más de MyRocks?
Cargas con muchas escrituras y presión en almacenamiento (costo por terabyte), donde la eficiencia del motor y del I/O marcan la diferencia económica.
¿MariaDB es solo un reemplazo de MySQL?
Puede serlo en casos sencillos, pero en despliegues a gran escala suele involucrar consideraciones de compatibilidad, gestión del stack, soporte y estrategia de plataforma.