私はklennepetteとBrianに同意します-いくつかの注意点があります。
データが本質的にリレーショナルであり、SQLで適切に機能するクエリの対象となる場合は、エキゾチックなハードウェア要件なしで数億のレコードに拡張できるはずです。
速度を上げるために、インデックス作成、クエリチューニング、およびリレーショナルモデルをときどき犠牲にすることに投資する必要があります。テーブルを設計するときは、少なくともパフォーマンスに注意する必要があります。たとえば、キーの文字列よりも整数を優先します。
ただし、ドキュメント中心の要件がある場合、フリーテキスト検索が必要な場合、または多くの階層関係がある場合は、もう一度確認する必要があります。
ACIDトランザクションが必要な場合は、トランザクションを気にしない場合よりも早くスケーラビリティの問題が発生する可能性があります（ただし、これが実際に影響を与える可能性は低いです）。長時間実行されるトランザクションや複雑なトランザクションがある場合、スケーラビリティは非常に急速に低下します。
スケーラビリティ要件を念頭に置いて、プロジェクトをゼロから構築することをお勧めします。私が過去に行ったことは、数百万のレコードが入力されたテスト環境をセットアップし（DBMonsterを使用しましたが、それがまだ存在するかどうかはわかりません）、次のような負荷テストツールを使用してこのデータベースに対して進行中のコードを定期的にテストします。 Jmeter。