Si todo se hace muy grande y hay recursos suficientes obviamente el numero de opciones aumenta, incluso usar motores de bases de datos de pago que tambien ofrecen mas y mejores recursos para conseguir un mejor balanceo de los datos.
Una cosa son aplicaciones como las que mencionas donde un usuario crea su base de datos para hacer una cosa concreta y la instala en su servidor...
Si se trata de crear una aplicacion unicliente y autoadminstrada obviamente tendrà una bbdd para cada cliente eso seria una cosa
Si se trata de crear una aplicacion que gestiona servicios a muchos clientes, adminstrada de forma central seria otra cosa distinta y la soluciones no serian las mismas.
Creo que el ejemplo de los bancos es bueno en este caso, yo puedo administrar mis cuentas via web, hacer tranferencias etc. con total seguridad de que no tocare nada que no sea mio apesar de que mis datos estan en una sola base de datos, o mejor seguro que estan en una nube de bases de datos organizada no por cliente sino por necesidades del banco o del sistema... obviamente usaran n servidores distintos ...
Si me instalo un wordpress version X y los desarroladores de wordpress crean la version X+1 es decisión mia si la voy a usar o no y si me compensa o no el trabajo de migrar los datos...
Cita: (disculpen si me equivoco pero balancear las cargas de un servidor mysql no implica duplicar los datos?)
No te equivocas, ni duplicar datos ni duplicar estructuras....ni separar por bbdd ni separar por tablas o todo a la vez, quiero decir que no hay una solución generica. Una solucion optima puede dejar de serlo si las previsones de crecimiento no se cumplen, tanto por exceso como por defecto. Si hago un diseño optimo para tarabajar con miles de millones de datos y acabo trabajando con unos pocos miles esa solucion seguramente no será la mejor, y exactamente lo mismo si se da la situación inversa.