多くの人がSPARQLを嫌うという感情に同意するかどうかはわかりません。 SPARQL 1.0にはいくつかの欠点がありましたが、設計の目的に非常にうまく対応しており、新しいイテレーションであるSPARQL 1.1は、サブクエリや集計など、元の仕様で見られると予想されるSQLからの多くの構造を追加して構築されています。 ＆セマンティクスを更新します。これは標準であり、SQLの方言とは対照的に、すべてのトリプルストアで同じ構文解析とセマンティクスを期待できるという事実は素晴らしい機能だと思います。
また、すべてのトリプルストアはグラフデータベースであると主張します。 Neo4jを使用した場合ほどうまくはいきませんが、RDFの特定のエッジにプロパティを配置できます。ただし、トリプルストアには、実際のクエリ言語、データを別のトリプルストアに簡単に移動できるw3c標準データ表現、および多くのトリプルストアでは、OWLに基づいて推論を実行できるという利点があります。
ほとんどのグラフデータベースのスケーラビリティについては何も知りませんが、一般的に、商用RDFデータベースは非常にうまくスケーリングします。すべてが数十億のトリプルに拡張でき、非常に多くのユースケースを処理します。スケールの処理方法はベンダーごとに大きく異なりますが、スケールアップまたはスケールアウト、クラスタリングなどがあります。また、それぞれの実装に一致する、かなり異なるmemおよびハードウェア要件も表示されます。私にとっては、EC2インスタンス（通常は2XLまたは4XL）を取得し、データを保持するのに十分な大きさのEBSをマウントする傾向があり、かなりうまく設定されています。
さらに、一部のトリプルストアは、Luceneまたは同様のテクノロジーと統合して、データに転置インデックスを提供します。現在、多くのストアに地理空間インデックスと時間インデックスが含まれ始めています。これらは非常に便利な機能であり、Neo4jのようなもので利用できるかどうかはわかりません。
そうは言っても、それらはリレーショナルデータベースほど拡張されることはなく、成熟していないだけです。ただし、「実際の」量のデータがある場合でも、混乱することはありません。もちろん、トリプルストアの利点の1つは推論であり、大規模な実行には注意が必要ですが、それがさまざまなOWLプロファイルが作成された理由の多くです。しかし、先を考えなければ、自分を隅に追いやることができます。
グラフデータベース、特にトリプルストアは、構築されている多くのアプリケーションにかなり適していると思いますが、それはすべてがそれらで行われるべきだという意味ではないと思います。他のものと同様に、それらは長所と短所を備えたツールであるため、アプリケーションに基づいて正しい選択を行う必要があります。しかし、彼らはおそらく、少なくとも最近は常に検討に値するでしょう。