Zgadzam się z klennepette i Brianem - z kilkoma zastrzeżeniami.
Jeśli Twoje dane są z natury relacyjne i podlegają zapytaniom, które dobrze współpracują z SQL, powinieneś być w stanie skalować do setek milionów rekordów bez egzotycznych wymagań sprzętowych.
Będziesz musiał zainwestować w indeksowanie, dostrajanie zapytań i sporadyczne poświęcanie modelu relacyjnego w imię szybkości. Przy projektowaniu tabel powinieneś przynajmniej ukłonić się w stronę wydajności – na przykład woląc liczby całkowite niż ciągi dla kluczy.
Jeśli jednak masz wymagania dotyczące dokumentów, potrzebujesz swobodnego wyszukiwania tekstu lub masz wiele relacji hierarchicznych, może być konieczne ponowne sprawdzenie.
Jeśli potrzebujesz transakcji ACID, możesz napotkać problemy ze skalowalnością wcześniej, niż jeśli nie interesują Cię transakcje (chociaż jest to mało prawdopodobne w praktyce); jeśli masz długotrwałe lub złożone transakcje, twoja skalowalność spada dość szybko.
Polecam zbudować projekt od podstaw, mając na uwadze wymagania dotyczące skalowalności. To, co zrobiłem w przeszłości, to skonfigurowanie środowiska testowego wypełnionego milionami rekordów (użyłem DBMonster, ale nie jestem pewien, czy to nadal jest dostępne) i regularnie testowałem kod w toku względem tej bazy danych za pomocą narzędzi do testowania obciążenia, takich jak Jmetr.
