Съгласен съм с klennepette и Brian - с няколко предупреждения.
Ако вашите данни по своята същност са релационни и са обект на заявки, които работят добре със SQL, трябва да можете да мащабирате до стотици милиони записи без екзотични хардуерни изисквания.
Ще трябва да инвестирате в индексиране, настройка на заявките и да правите от време на време жертва на релационния модел в интерес на скоростта. Трябва поне да кимнете на производителността, когато проектирате таблици – предпочитайки цели числа пред низове за ключове, например.
Ако обаче имате изисквания, ориентирани към документите, нуждаете се от свободно търсене на текст или имате много йерархични връзки, може да се наложи да погледнете отново.
Ако имате нужда от ACID транзакции, може да срещнете проблеми с мащабируемостта по-рано, отколкото ако не се интересувате от транзакции (въпреки че това все още е малко вероятно да ви засегне на практика); ако имате продължителни или сложни транзакции, вашата мащабируемост намалява доста бързо.
Бих препоръчал изграждането на проекта от самото начало, като се имат предвид изискванията за мащабируемост. Това, което направих в миналото, е да настроя тестова среда, населена с милиони записи (използвах DBMonster, но не съм сигурен дали това все още съществува) и редовно да тествам кода в процес на работа спрямо тази база данни, използвайки инструменти за тестване на натоварване като Jmeter.
