Concordo com klennepette e Brian - com algumas ressalvas.

Se seus dados são inerentemente relacionais e sujeitos a consultas que funcionam bem com SQL, você deve ser capaz de escalar para centenas de milhões de registros sem requisitos de hardware exóticos.

Você precisará investir em indexação, ajuste de consulta e fazer sacrifícios ocasionais ao modelo relacional em nome da velocidade. Você deve pelo menos acenar para o desempenho ao projetar tabelas – preferindo números inteiros a strings para chaves, por exemplo.

Se, no entanto, você tiver requisitos centrados em documentos, precisar de pesquisa de texto livre ou tiver muitos relacionamentos hierárquicos, talvez seja necessário procurar novamente.

Se você precisar de transações ACID, poderá ter problemas de escalabilidade mais cedo do que se não se importar com as transações (embora seja improvável que isso o afete na prática); se você tiver transações complexas ou de longa duração, sua escalabilidade diminuirá rapidamente.

Eu recomendaria construir o projeto desde o início com os requisitos de escalabilidade em mente. O que fiz no passado foi configurar um ambiente de teste preenchido com milhões de registros (usei o DBMonster, mas não tenho certeza se ainda existe) e testar regularmente o código de trabalho em andamento nesse banco de dados usando ferramentas de teste de carga como Jmetro.