SQLite数据库的实际最大实际大小是多少？

根据有关SQLite适当用法的这篇文章，它说，尽管SQLite的限制为140 TB，但客户端/服务器RDBMS可能会更好地工作：

SQLite数据库的大小限制为140 TB（2 ⁴⁷字节，128 TB）。即使可以处理更大的数据库，SQLite也会将整个数据库存储在单个磁盘文件中，而许多文件系统将文件的最大大小限制为小于此大小。因此，如果您正在考虑这种规模的数据库，那么最好考虑使用一个客户机/服务器数据库引擎，该引擎将其内容分布在多个磁盘文件中，甚至可能分布在多个卷中。

总的来说，我同意这一点，但是得知SQLite的最大限制如此之高，我感到很惊讶！根据我的经验，我已经使用了许多SQL Server数据库，其大小约为30-100GB。我还间接使用Oracle，Postgres或Cassandra处理更大的数据库。其中，至少就我所知，没有一个接近140TB。我不是DBA，因此根据我的直接经验，我认为这是“大笔”的事情。

对于数据库很小的情况，我只考虑过SQLite。最多几十兆。

阅读本文后，我仍然不相信要考虑将SQLite用于可能需要数百GB数据的任何事情。但是我想知道我是否一直在低估它的功能。在实际使用中，SQLite数据库的实际最大大小限制是多少？

实际限制（某些Sqlite数据库的大小）与数据文件的实际限制相同。这个限制取决于您的计算机和系统。在当前的Linux桌面上，我无法承受比350Gbyte大得多的文件（因为根据经验，我避免让一个文件占用超过一半磁盘分区的空间）。顺便说一句，该实际限制还影响到其他SQL RDBMS，例如PostGreSQL或MariaDB（但其中大多数将数据保存在多个文件中，您可以将其保留在不同的文件系统上，并且其中一些能够管理远程计算机上的分布式数据。 ）

阅读本文后，我仍然不相信要考虑将SQLite用于可能需要数百GB数据的任何事情

你是对是错。

您是对的，因为在当今的计算机（笔记本电脑和台式机，而不是超级计算机或数据中心服务器）上，一百GB的磁盘空间仍然很大。因此，在实践中，如果考虑到这么大的数据库，则最好想象一台真正的SQL服务器（例如PostGreSQL），因为您可能需要非常远程的访问，有效的并发访问以及分布式的数据和表。

您错了（原则上，我从没有尝试过），因为假设您有一个文件系统能够处理这么大的文件（可能是两个），SQLite很可能能够（有时经过测试）处理数百GB的数据库。他们至少）。

我当然会（有时）考虑将SQLite用于数十个千兆字节的数据库（并且我确实曾经尝试过这么大的.sqlite文件，即40GB的IIRC）。在当前的（非超级计算机）计算机上，我会犹豫是否拥有数百GB的SQLite数据库，仅仅是因为按照今天的实践，这样的文件很大。

IIRC一些出售专用文件系统机器的硬件供应商曾经说过一个TB级的sqlite应用程序（但我可能错了）。

当然，SQLite的性能取决于（像所有的SQL数据库）很多表，它们的索引，涉及的SQL查询的数量和宽度。而且，您不希望同时访问（通过许多不同的进程），而应该使用事务处理（根据经验，即使在只有几兆字节的小型SQLITE数据库上，您也确实想用BEGIN TRANSACTION＆来包装例如数千个插入请求）END TRANSACTION，不这样做会使Sqlite的运行速度大大降低-超过10倍-）。

根据个人经验，通过适当的配置和组织，SQLite能够管理大于可用RAM的数据库（因此30G字节不是问题）-但您可能希望索引适合RAM！

如果您碰巧为“超级计算机”或昂贵的工作站（例如512GB的RAM，8TB的磁盘和512GB的SSD）编写代码，那么您肯定可以拥有TB级的Sqlite数据库。但是，仅当一个（或很少）进程正在访问该数据库时，您才想这样做。如果您有十几个进程同时访问同一数据库，则最好安装真正的SQL RDBMS（例如MariaDB或PostGreSQL）

还要注意，虽然.sqlite数据库文件的（二进制）格式被记录为“可移植”，但我还是更喜欢以SQL 文本格式（使用sqlite3 mydb.sqlite .dump > mydb.sql）备份数据库。然后，我还需要一些额外的磁盘空间用于该文本转储（这降低了实际限制）。

通常，Sqlite并不是瓶颈。但是磁盘可能是。

PS。可以使用GDBM将相同的推理应用于大型索引文件。

^{PPS。在我的MELT监视器（GPLv3免费软件，在github上）的expjs分支（2016年9月）中，我将整个应用程序堆持久保存在一个新的Sqlite数据库中的JSON中。我已经对数百万个对象（相当大的对象）进行了微小的实验，没有令人惊讶的地方。YMMV。}