Je suis d'accord avec klennepette et Brian - avec quelques mises en garde.
Si vos données sont intrinsèquement relationnelles et soumises à des requêtes qui fonctionnent bien avec SQL, vous devriez pouvoir évoluer jusqu'à des centaines de millions d'enregistrements sans exigences matérielles exotiques.
Vous devrez investir dans l'indexation, le réglage des requêtes et sacrifier occasionnellement le modèle relationnel dans l'intérêt de la vitesse. Vous devriez au moins faire attention aux performances lors de la conception de tables - en préférant les entiers aux chaînes pour les clés, par exemple.
Si, toutefois, vous avez des exigences centrées sur les documents, avez besoin d'une recherche en texte libre ou avez de nombreuses relations hiérarchiques, vous devrez peut-être revoir.
Si vous avez besoin de transactions ACID, vous pouvez rencontrer des problèmes d'évolutivité plus tôt que si vous ne vous souciez pas des transactions (bien que cela ne vous affecte toujours pas dans la pratique); si vous avez des transactions longues ou complexes, votre évolutivité diminue assez rapidement.
Je recommanderais de construire le projet à partir de zéro en gardant à l'esprit les exigences d'évolutivité. Ce que j'ai fait dans le passé est de configurer un environnement de test rempli de millions d'enregistrements (j'ai utilisé DBMonster, mais je ne sais pas si c'est toujours le cas), et de tester régulièrement le code en cours de travail par rapport à cette base de données à l'aide d'outils de test de charge comme Jmètre.
