Jeg er enig med klennepette og Brian - med et par forbehold.
Hvis dine data i sagens natur er relationelle og underlagt forespørgsler, der fungerer godt med SQL, bør du være i stand til at skalere til hundredvis af millioner af poster uden eksotiske hardwarekrav.
Du bliver nødt til at investere i indeksering, forespørgselstuning og lejlighedsvis at ofre den relationelle model af hensyn til hastigheden. Du bør i det mindste nikke til ydeevne, når du designer tabeller - foretrækker f.eks. heltal frem for strenge for nøgler.
Men hvis du har dokumentcentrerede krav, har brug for fritekstsøgning eller har masser af hierarkiske relationer, skal du muligvis kigge igen.
Hvis du har brug for ACID-transaktioner, kan du løbe ind i skalerbarhedsproblemer tidligere, end hvis du er ligeglad med transaktioner (selvom det stadig er usandsynligt, at det vil påvirke dig i praksis); hvis du har langvarige eller komplekse transaktioner, falder din skalerbarhed ret hurtigt.
Jeg vil anbefale at bygge projektet fra bunden med skalerbarhedskrav i tankerne. Det, jeg har gjort tidligere, er at opsætte et testmiljø fyldt med millioner af poster (jeg brugte DBMonster, men jeg er ikke sikker på, om det stadig findes) og regelmæssigt teste igangværende arbejde-kode mod denne database ved hjælp af load-testværktøjer som f.eks. Jmeter.