これは、Twitterクローンにとって理想的なスキーマではありません。主な問題は、「投稿」が増え続ける配列であるということです。つまり、mongoは、ドキュメントのパディングが不足しているため、数件の投稿ごとに大量のドキュメントを移動する必要があります。さらに、ドキュメントには厳しい（16MB）サイズ制限があり、このスキーマはせいぜい制限的です。
理想的なスキーマは、Twitterの負荷を期待するかどうかによって異なります。保守性と使いやすさの点で「完璧な」mongodbスキーマは、Twitterのスループットで何かに使用するものと同じではありません。たとえば、前者の場合、投稿ごとにドキュメントを含む投稿コレクションを使用します。高スループットのシナリオでは、投稿の小さなグループ（たとえば、「もっと見る」ページごとに1つ）のバケットドキュメントの作成を開始します。さらに、高スループットのシナリオでは、フォロワーのタイムラインを個別のユーザータイムラインドキュメントで最新の状態に保つ必要がありますが、低スループットのシナリオでは、単純にクエリを実行できます。