Estoy de acuerdo con klennepette y Brian, con un par de advertencias.
Si sus datos son inherentemente relacionales y están sujetos a consultas que funcionan bien con SQL, debería poder escalar a cientos de millones de registros sin requisitos de hardware exóticos.
Deberá invertir en la indexación, el ajuste de consultas y hacer sacrificios ocasionales al modelo relacional en aras de la velocidad. Al menos, debe reconocer el rendimiento al diseñar tablas, por ejemplo, prefiriendo los números enteros a las cadenas para las claves.
Sin embargo, si tiene requisitos centrados en documentos, necesita búsqueda de texto libre o tiene muchas relaciones jerárquicas, es posible que deba volver a buscar.
Si necesita transacciones ACID, es posible que tenga problemas de escalabilidad antes que si no le interesan las transacciones (aunque es poco probable que esto le afecte en la práctica); si tiene transacciones complejas o de larga duración, su escalabilidad disminuye con bastante rapidez.
Recomendaría construir el proyecto desde cero teniendo en cuenta los requisitos de escalabilidad. Lo que he hecho en el pasado es configurar un entorno de prueba poblado con millones de registros (utilicé DBMonster, pero no estoy seguro de si todavía está disponible) y probar regularmente el código de trabajo en progreso en esta base de datos usando herramientas de prueba de carga como Jmetro.
