Durante años, la idea de que “SQL no escala” ha funcionado como atajo mental: cuando el producto crece, se asume que tocará “salirse” de una base de datos relacional y abrazar alternativas diseñadas para repartir datos y tráfico desde el minuto uno. El matiz incómodo es que esa narrativa se cae en cuanto uno mira cómo operan varias de las plataformas más exigentes del planeta.
La realidad es menos épica, pero mucho más útil: escalar con SQL suele ser un problema de arquitectura, operación y disciplina de ingeniería, no de “limitaciones intrínsecas” del modelo relacional. En otras palabras: si SQL sirve para quienes viven bajo picos de tráfico extremos, también puede servir —con mucha probabilidad— para la mayoría de productos que no van a rozar esas condiciones.
Shopify, el e-commerce y la trastienda de MySQL
En el mundo del comercio electrónico, hay un momento del año que separa la teoría del barro: campañas de alto tráfico, incidentes, degradaciones controladas y decisiones rápidas. Shopify ha contado públicamente parte de su enfoque técnico alrededor de MySQL y piezas de infraestructura que ayudan a absorber picos, como ProxySQL, que gestiona conexiones y distribuye tráfico entre primarios y réplicas de lectura. En su caso hablan incluso de operar miles de instancias de ProxySQL y de mecanismos para aplicar reglas de enrutado o mitigación con seguridad operativa cuando el sistema está bajo presión.
No hace falta convertir esto en un “SQL gana”: lo relevante es la lección. Cuando el tráfico aprieta, la estrategia suele ser mover lecturas a réplicas, controlar el acceso, proteger al primario y automatizar cambios, más que tirar la base de datos por la borda.
Meta y MyRocks: cuando el problema es I/O y coste, no “SQL vs NoSQL”
Otro ejemplo clásico está en Meta (Facebook), que ha trabajado con MyRocks, un motor de almacenamiento para MySQL orientado a optimizar espacio y escrituras usando la familia de técnicas LSM (vía RocksDB). El proyecto se ha documentado y publicado de forma abierta, incluyendo referencias técnicas y repositorios asociados.
Aquí la enseñanza es casi quirúrgica: a cierta escala, la discusión deja de ser “relacional o no” y pasa a ser coste por terabyte, amplificación de escritura, latencias p99, compacción, y eficiencia del almacenamiento. SQL no desaparece; se ajusta el subsuelo.
YouTube y Vitess: el “sharding” no es una religión, es una técnica
Para escalar horizontalmente, el concepto que más se repite es el particionado (sharding): dividir datos por alguna clave (usuario, tenant, región, etc.) para repartir carga. En el ecosistema MySQL, el caso más conocido es Vitess, un proyecto que nació en YouTube y que hoy está ampliamente adoptado, precisamente para operar MySQL a gran escala con particionado y capa de orquestación.
De nuevo, el punto no es “usa Vitess”. El punto es entender que SQL puede escalar horizontalmente si se asume que la topología (y la aplicación) deben diseñarse para ello.
PostgreSQL también juega en primera división: Instagram y el crecimiento “sin cambiar de base”
El relato de “SQL no escala” también se cae mirando a PostgreSQL. Instagram explicó hace años cómo Postgres siguió siendo su “fundación sólida” mientras crecían, incluyendo prácticas como particionado horizontal y optimización (índices parciales, índices funcionales, y otras técnicas operativas).
Esto importa porque desactiva otro mito: que “Postgres es para cosas medianas” y “MySQL es para web”. En la práctica, ambos pueden sostener cargas enormes si el diseño y la operación acompañan.
Más ejemplos prácticos: Pinterest y Airbnb en el mundo MySQL
En ingeniería real, muchas veces el debate no gira en torno a “qué base de datos elijo”, sino a “cómo reduzco riesgo hoy”. Pinterest ha descrito su uso de shards de MySQL y prácticas para gestionar escala operativa en torno a esa decisión.
Airbnb, por su parte, ha compartido casos donde el comportamiento de réplicas MySQL y la latencia asociada importan tanto como el propio esquema, mostrando que la escalabilidad es también una cuestión de observabilidad y control fino del sistema.
Y MariaDB: el “fork” que se convirtió en alternativa operativa
Cuando aparece MariaDB en la conversación, suele hacerlo como “MySQL compatible”. En la práctica, para muchas organizaciones es una decisión operativa y de gobierno tecnológico. Un ejemplo muy citado es el uso de MariaDB en el ecosistema Wikimedia, que se menciona habitualmente como referencia pública de 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é, particionado por aplicación | Madurez, tooling, rendimiento probado en web | Writes 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 base, agiliza respuesta operativa | Añade capa crítica (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/escrituras manteniendo SQL | Coste y eficiencia I/O | Trade-offs propios de LSM (compacción, tuning) | Meta (Facebook) |
| PostgreSQL | Réplicas, particionado, optimización avanzada de consultas | Potencia SQL, extensiones, robustez | Escalado horizontal requiere diseño (como en cualquier SQL) | |
| MariaDB | Similar a MySQL (réplicas/cluster según diseño) | Compatibilidad y opciones de despliegue | Variaciones por versión/compatibilidad según features | Wikimedia (referencia citada) |
| Distributed SQL (Spanner/Cockroach/Yugabyte) | Distribución nativa con consistencia fuerte (según sistema) | Menos “pegamento” externo para repartir datos | Complejidad y coste; elección muy dependiente del caso | (Varía por plataforma y proveedor) |
La foto que deja esta comparativa es clara: SQL escala, pero no “por arte de magia”. Escala cuando se diseña para ello: separar lecturas y escrituras, elegir claves de particionado realistas, asumir el coste de la operación distribuida y construir automatización y observabilidad.
Conclusión: el debate útil no es “SQL sí/no”, sino “qué arquitectura necesito”
Para la mayoría de equipos, la decisión más rentable suele ser pragmática: exprimir bien 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 el sistema ya demuestra —con datos— que lo exige.
El aprendizaje que dejan Shopify, Meta, YouTube o Instagram no es que haya una base de datos “ganadora”. Es que los sistemas grandes se ganan con ingeniería: topologías, proxies, particionado, optimización, y operaciones serias.
Preguntas frecuentes
¿Cuándo deja de ser suficiente “primario + réplicas” en MySQL o PostgreSQL?
Cuando el cuello de botella real está en escrituras o en contención (locks, hot rows, o índices que no aguantan), y el particionado por dominio empieza a ser inevitable.
¿Vitess es solo para “hiperescalares”?
No necesariamente, pero sí implica un salto: compensa cuando el sharding deja de ser una excepción y se convierte en norma operativa.
¿Qué tipo de producto se beneficia más de MyRocks?
Cargas con muchas escrituras y presión de almacenamiento (coste/terabyte), donde la eficiencia del motor y el I/O determinan la viabilidad económica.
¿MariaDB es “solo un reemplazo” de MySQL?
Puede serlo en casos simples, pero en despliegues grandes la decisión suele incluir factores de compatibilidad, gobierno del stack, soporte y estrategia de plataforma.
