SQLiteデータベースの現実的な実際の最大サイズとは何ですか？
SQLiteの適切な用途 に関するこの記事によると、SQLiteは140テラバイトに制限されていますが、クライアント/サーバーRDBMSはよりよく機能する可能性があります。
SQLiteデータベースのサイズは140テラバイト（247 バイト、128ティビバイト）。また、より大きなデータベースを処理できる場合でも、SQLiteはデータベース全体を単一のディスクファイルに格納し、多くのファイルシステムはファイルの最大サイズをこれよりも小さいものに制限しています。したがって、この規模のデータベースを検討している場合は、そのコンテンツを複数のディスクファイルに、そしておそらく複数のボリュームに分散するクライアント/サーバーデータベースエンジンの使用を検討することをお勧めします。
一般的に私はこれに同意しますが、SQLiteの最大制限が非常に高いことを知って驚きました！私の経験では、30〜100 GBのサイズのSQL Serverデータベースをかなり使用しました。また、Oracle、Postgres、またはCassandraを使用して、はるかに大きなデータベースを間接的に操作しました。それらのうち、少なくとも私の知る限りでは、140 TBに近づいているものはありませんでした。私はDBAではないので、これは直接的な経験から「大規模」と見なすものです。
データベースが非常に小さい状況でのみSQLiteを検討しました。最大で数十メガバイト。
この記事を読んだ後でも、何百ギガバイトも必要になる可能性のあるものについてSQLiteを検討することに確信が持てません。しかし、私はその能力を過小評価していたのではないかと思っています。実際に使用しているSQLiteデータベースの現実的な最大サイズ制限とは何ですか？
（一部のSqliteデータベースのサイズの）現実的な制限は、データファイルの現実的な制限と同じです。そして、その制限はあなたのコンピュータとシステムの多くに依存します。私の現在のLinuxデスクトップでは、350Gバイトのファイルよりもはるかに大きい容量を用意することはできません（経験則として、1つのファイルでディスクパーティションの半分以上を使用することは避けているため）。ところで、その実用的な制限は、PostGreSQLやMariaDBなどの他のSQL RDBMSにも影響します（ただし、これらのほとんどはseveralファイルにデータを保持します。ファイルシステム、そしてそれらのいくつかはリモートマシン上の分散データを管理することができます...）
この記事を読んだ後でも、何百ギガバイトも必要となる可能性があるものについてSQLiteを検討することに確信はありません。
あなたは正しいと間違っています。
今日のコンピューター（スーパーコンピューターやデータセンターサーバーではなく、ラップトップとデスクトップ）では、100ギガバイトはまだかなり大きなディスク領域であるためです。したがって、実際には、このような大規模なデータベースについて考える場合は、特に実際のSQLサーバー（PostGreSQLの1つ）を想像することになるでしょう。リモートアクセス、効果的な同時アクセス、そしておそらく分散データとテーブルが必要になる可能性があるからです。
SQLiteはおそらく数百ギガバイトのデータベースを処理できる（そしてテストされている）可能性があるため、あなたは（原則として、私は試したことはありません）間違っています。それらは少なくとも）。
私は確かに（ときどき）数十ギガバイトのデータベースにSQLiteを検討します（そして、40GバイトのIIRCのような大きな.sqliteファイルを一度試してみました）。現在の（スーパーコンピューターではない）マシンでは、何百ギガバイトものSQLiteデータベースを持つことはためらいます。
IIRC専門のファイルシステムマシンを販売している一部のハードウェアベンダーは、テラバイトのsqliteアプリケーションについて一度話してくれました（しかし、私は間違っているかもしれません）。
もちろん、SQLiteのパフォーマンスは（すべてのSQLデータベースのように）テーブルの数と幅、それらのインデックス、関連するSQLクエリの数に依存します。そして、（多くの異なるプロセスによる）同時アクセスをしたくないので、トランザクションを使用する必要があります（経験上、数メガバイトの小さなSQLITEデータベースでも、たとえば数千の挿入要求をBEGIN TRANSACTIONでラップする必要があります。 ＆END TRANSACTION、それを行わないと、Sqliteが10倍以上の大きな要因でスローダウンします）。
個人的な経験から、適切な構成と構成により、SQLiteは利用可能なデータベースよりも大きいデータベースを管理できますRAM（30Gbytesは問題ではないため）-おそらく、インデックスをRAMに収めたい！
「スーパーコンピュータ」または高価なワークステーション（たとえば、512GバイトのRAMおよび8Tバイトのディスクと512GバイトのSSD）を使用）で何かをコーディングする場合、テラバイトのSqliteデータベースを使用できます。しかし、おそらく、1つ（または非常に少数）のプロセスがそのデータベースにアクセスしている場合にのみ、それを実行します。同じデータベースに同時にアクセスしているプロセスが数十ある場合は、実際のSQL RDBMS（MariaDBまたはPostGreSQL）をインストールすることをお勧めします。
また、.sqliteデータベースファイルの（バイナリ）形式は documented が「移植可能」であることを示していますが、データベースをSQLtextual形式（sqlite3 mydb.sqlite .dump > mydb.sqlを使用）。次に、そのテキストダンプ用に追加のディスク領域も必要です（これにより、現実的な制限が下がります）。
通常、Sqliteはボトルネックではありません。しかし、ディスクはそうかもしれません。
PS。 [〜＃〜] gdbm [〜＃〜] を使用して、同じ推論を大きなインデックス付きファイルに適用できます。
PPS。私のMELTモニター（GPLv3フリーソフトウェア、github上の）の expjs ブランチ（2016年9月）に persisting 新しいSqliteデータベース内のJSONでのアプリケーションヒープ全体です。私は数百万のオブジェクト（かなり「大きい」）で小さな実験を実行しましたが、驚くことはありません。 YMMV。