トラフィックの少ないサイトの本番データベースとしてのSQLite？
おそらく20人の同時ユーザーを受け入れるサイトの実稼働データベースとしてSQLiteを使用することを検討していますが、ピークはその数倍になる可能性があります（サイトはオープンインターネットでアクセス可能であり、常に誰かがリンクを投稿して、多くの人を一度にサイトに誘導する可能性があります）。
SQLiteは可能ですか？
私はそれが理想的な生産シナリオではないことを知っています。これが現実的な可能性の範囲内であるかどうかを私は尋ねているだけです。
SQLiteはいかなる種類の同時実行性もサポートしていないため、運用WebサイトでSQLiteを実行すると問題が発生する可能性があります。 「より軽量な」データベースを探している場合は、CouchDBなどの最新のオブジェクトドキュメントストアを試してみてください。
必ず、SQLiteに対する開発を続けてください。最初はそれを使用しても問題ないでしょう。ただし、アプリケーションのユーザー数が多い場合は、PostgresまたはMySQLに移行する必要があります。
SQLiteの作者はこれに対処します ウェブサイト上 ：
SQLiteは、ほとんどの低から中程度のトラフィックのWebサイト（つまり、ほとんどのWebサイト）のデータベースエンジンとして最適です。 SQLiteが処理できるWebトラフィックの量は、Webサイトがデータベースをどれだけ頻繁に使用するかによって異なります。一般的に言って、1日あたりのヒット数が10万未満のサイトはSQLiteで正常に動作するはずです。 10万ヒット/日の数値は控えめな見積もりであり、ハードな上限ではありません。 SQLiteは、その10倍のトラフィック量で動作することが実証されています。
SQLite Webサイト（ https://www.sqlite.org/ ）はもちろんSQLite自体を使用しており、この記事の執筆時点（2015）では、1日あたり約400K〜500KのHTTPリクエストを処理しています。 15〜20％はデータベースに接続する動的ページです。動的コンテンツは、Webページごとに約200のSQLステートメントを使用します。このセットアップは1つのVMで実行されます。これは、物理サーバーを他の23と共有しますが、ほとんどの場合、負荷平均を0.1未満に保ちます。
ですから、長くて短いのは当然だと思います。うまくいかない場合でも、エンタープライズクラスのデータベースに移行するのは簡単です。ただし、スキーマには注意を払い、成長と効率を念頭に置いてデータベースを設計してください。
これが a thread で、本番WebアプリケーションでのSQLiteの使用に関するいくつかの独立したコメントがあります。いくつかの結果が混在しているようです。
編集（2014）：
この回答が投稿されたため、SQLiteは マルチスレッドモード および 先読みロギングモード を備えています。これは、低中トラフィックサイトへの適合性の評価に影響する可能性があります。
Charles Leiferが ブログ投稿 にSQLiteのWAL（先読みロギング）機能と、適切な使用例に関するよく考えられた意見について書いています。
SQLiteからの小さな抜粋 website がすべてを語っています。
データはアプリケーションからネットワークによって分離されていますか？ →client/serverを選択します
多くの同時ライター？ →client/serverを選択します
ビッグデータ？ →クライアント/サーバーを選択
それ以外の場合→SQLiteを選択してください！
SQLiteは「正常に動作する」（もちろん動作しなくなるまで）
SQLiteは内部データベースによく使用されます。従業員ディレクトリ、イベントのカレンダー、およびその他のイントラネットサービスはすべて、軽量データベースで実行されます。これらのアプリをmySQLのような「実際の」データベースで実行する規模で実行するのは、大きなやりすぎです。これは、単一のミッドレンジコンピューターで他の4台の仮想マシンと一緒に実行されていることを考慮に入れる場合に特に当てはまります。
ある時点で、外側に面したサイトがsqlite dbで数か月実行され、1回の再起動のみが必要でした。明らかに、それは非常に低いトラフィックでしたが、それが何をするのかについてうまくいっていました。
絶対に書き込みがない環境で同様のオプションが見つかり、SQLiteを使用して選択しました。
件名については、私の ブログ投稿 を参照してください。
このソリューションを理論的に可能にする主な前提は、SQLiteデータベースが完全に読み取り専用であることです。私たちのサーバーコードは決してそれを変更すべきではありません。読み取りロックがないので、これはすべてのロック問題を解決します。書き込みがないときにSQLiteの高スループットの読み取りに問題があると言っているインターネット上の場所を見つけることはできませんでした。
人々は並行性の問題について話しますが、sqliteには着信要求をキャッシュして、しばらく待つようにする方法があります。すぐにタイムアウトすることはありません。
デフォルトのタイムアウト設定はゼロから始まります。つまり、すぐにタイムアウトし、それはナンセンスです。多分人々はこの設定を調整しなかったのですか？
それは主にあなたの読み取り/書き込み比率がどうなるかに依存すると思います。データベースからの読み取りがほとんどの場合、問題はありません。 SQLiteでのマルチユーザー書き込みは、データベースをロックする方法が原因で問題になる可能性があります。
キューイングを使用すると、SQLiteでの同時書き込みに関する多くの問題を回避することもできるようです。 sqlite dbに直接書き込む代わりに、キューに書き込んでから、先入れ先出しモードで順番にsqlite dbに書き込みます。アプリケーションを書く価値があるか、クライアント/サーバーDBに移動するだけの場合、アプリケーションがこれを必要とする場所に到達するかどうかはわかりませんが、考えてみてください。
非常にトラフィックの少ないWebサーバー（これはゲノムデータベースです）で使用しており、何の問題もありません。しかし、SELECTステートメントしかありません関係するDBへの書き込みはありません。
すでに素晴らしい答えに追加するには：この場合、サーバーレスソリューションを使用しているので、レプリケーション、またはデータベースのあらゆる種類の水平スケーリング、およびその他の高度なオプションに別れを告げることができます。複数のユーザーが同じ正確な情報を更新している場合も、これは最良の選択ではありません。将来データベースをシャーディングする場合は、データを移行して別の場所に移動する必要があります。また、ロードバランサーと複数のシステムが関与している場合、sqliteを使用すると、データの中心性を維持することが困難になります。これらは、推奨されない理由の一部にすぎません。小規模なプロジェクトに最適で、開発に最適です。
サイトの利用状況により異なります。ほとんどの場合、データを読み取るだけの場合は、DBのほとんどのものを使用し、アプリケーションにデータをキャッシュして、優れたパフォーマンスを実現できます。