SQLite は、ほとんどの、負荷が低いあるいは中くらいのウェブサイト（それはつまり、ほとんどのウェブサイトです）のためのデータベースエンジンとして、素晴らしくうまくはたらきます。SQLite が扱うことのできるウェブ負荷は、そのウェブサイトが、自分のデータベースをどのくらいヘビーに使うかに依存します。一般的に言って、100K ヒット／日以下を得るサイトならどれでも、SQLite でうまくいくはずです。100K ヒット／日という数字は、保守的な見積もりであり、厳格な上限値ではありません。SQLite はその１０倍の負荷の下でうまくはたらくことを示してきました。
もちろん、SQLite ウェブサイト (https://www.sqlite.org/) 自身が、 SQLite を使っています。そして、これを書いている今(2015) それは、一日に 400K から 500K の HTTP 要求を扱います。その15-20% は、データベースをさわる、ダイナミックなページです。ダイナミックなコンテンツは、一つのウェブページごとに、約 200 の SQL 文 を使います。この構成は、２３台の他の仮想マシンと物理サーバを共有する、単一の仮想マシンで動作しています。そしてそれでも、ほとんどの時間で、負荷は 0.1 以下のままです。
クライアント／サーバ RDBMS がよりうまくはたらくことのある状況
（中略）
・ 高ボリュームのウェブサイト
SQLite はウェブサイトのバックエンドとして、通常はうまくはたらきます。しかし、そのウェブサイトがライトが頻繁だったり、あまりに忙しいので複数のサーバを必要とする場合は、SQLite ではなく、エンタープライズ級のクライアント／サーバデータベースエンジンを使うことを考えましょう。
SQLite は、無限個数の同時のリーダーをサポートします。しかし、ある時間のいずれの時でも一つのライターしか許しません。多くの状況でこれは問題ではありません。ライターは、キューにつながります。それぞれのアプリケーションは自分のデータベースの仕事を素早く行って進んでいきます。そしてロックは数十ミリ秒以上続くことはありません。しかしアプリケーションによってはこれ以上の同時実行性を必要とするものがあります。そのようなアプリケーションは異なるソリューションを探す必要があるかもしれません。
リードがメイン（かつシングルホスト）ならぶっちゃけMySQLより性能は出るんだよなぁ...
ただし、書き込みは常に1プロセスしか許可されない（ファイルベースなので）ので、書き込みが多いサイトだと逆にロック解放待ちが大量に発生してパフォーマンスが死ぬほど悪くなるし、最悪待ち行列がメモリを食いつぶして死ぬ。