回答:
あなたの質問に対する簡単な答えはありませんが、ここではいくつかのことを考えます。
まず、心配するのはスケールだけではありません。データで何をするかです。500 TBのテーブルに30 TBのデータがあり、レポートがほとんどない単純なOLTPを実行している場合、問題が多すぎるとは思わないでしょう。PostgreSQLには32 TBのデータベースがあります。ただし、同時にすべてのディスクをヒットする必要があるため、パフォーマンスは多少低下します。同様に、データが50TBであるが、約100GBの一般的なヒットセットがある場合、dbのその部分をメモリに保持するのに十分なRAMを備えたサーバーを構築できます。
一方、1TBのデータからモード（最も一般的な値）を取得しようとする場合、使用しているシステムは関係ありません。これは、シャーディングの有無にかかわらず痛みを伴います。（編集：シャーディングは、実際、この問題を悪化させる可能性があります。）
MySQLとPostgreSQLで巨大なデータベースで遭遇する主な問題は、どちらもクエリ内並列処理をサポートしていないという事実に関係しています。言い換えれば、クエリは単一のスレッドによって単一のブロックとして実行され、断片に分割して個別に実行することはできません。多くの場合、これは大量のデータに対して大規模な分析クエリを実行する場合の問題です。ここで、Postgres-XCとGreen Plumがストレージを実行から分離し、コーディネーターレベルでこれを実行できるため、救助に出ます。Postgres-XCとGreen Plumは基本的に内部でシャーディングを使用しますが、コーディネーターはすべての一貫性をグローバルに適用することに注意してください。
クエリ内並列処理を使用すると、クエリを分割し、さまざまなプロセッサ/ディスクI / Oチャネルでその一部を実行し、結果セットの一部をレポートして、アセンブルしてアプリケーションに返すことができます。繰り返しますが、これは通常、トランザクション処理の負荷ではなく分析の負荷に最も役立ちます。
2つ目は、VerticaやGreenplumなどの一部のシステムは、情報の列を一緒に格納することです。これにより、OLTPの観点からシステムの使用が難しくなり、そこでのパフォーマンスが低下しますが、大規模な分析ワークロードのパフォーマンスが大幅に向上します。したがって、これはワークロード固有のトレードオフです。
そのため、サイズが1〜2 TBを超えると、システムとワークロードの間の多くのトレードオフに直面することになります。繰り返しになりますが、これはデータベース、ワーキングセットのサイズなどに固有です。ただし、この時点では、スノーフレークシステム、つまりワークロードに合わせてカスタマイズされたシステムを使用する必要があります。
もちろん、これは制限が一般的に定量化できないことを意味します。
編集：私は今、PostgreSQLの意思決定支援とトランザクション処理ワークロードの混合を処理する9TBのデータベースで作業しました。唯一の最大の課題は、データセットの大部分を占める質問がある場合、回答を待つ必要があることです。
ただし、基本事項（インデックス、自動バキューム、これらが低レベルでどのように機能するかなど）と十分なコンピューティングリソースに細心の注意を払うと、これらは完全に管理可能です（Pgで30TBの範囲内で十分管理できると推定されます）。
Edit2：一度100 TBに達すると、動作はデータセットによって異なります。PostgreSQLで最初にテーブルあたり32 TBの制限に達するため、この範囲にスケールしない1つに現在取り組んでいます。