2020年更新，大约11年前这个问题被发布，后来被关闭，阻止了更新的答案。
这里写的几乎都过时了。曾几何时，sqlite被限制在内存容量或2gb的存储空间(32位)或其他流行的数字…那是很久以前的事了。
官方限制列在这里。实际上，只要有可用的存储空间，sqlite就可能工作。它适用于比内存大的数据集，它最初是在内存很薄的时候创建的，从一开始就非常重要。
存储100gb的数据绝对没有问题。它可能可以很好地存储TB，但最终这是你需要质疑SQLite是否是最好的工具，你可能想要一个完整的数据库的功能(远程客户端，并发写入，只读副本，分片等…)
原:
我知道即使sqlite支持超大的数据库文件，sqlite也不能很好地处理它们(sqlite网站上曾经有一条评论说，如果你需要超过1GB的文件大小，你可能要考虑使用企业rdbms。再也找不到它了，可能与sqlite的旧版本有关)。
然而，出于我的目的，我想在考虑其他解决方案之前了解它到底有多糟糕。
我说的是从2GB开始的千兆字节范围的sqlite数据文件。 有人有这方面的经验吗?任何建议/想法吗?
当前回答
我认为关于sqlite缩放的主要抱怨是:
单进程写。 没有镜像。 没有复制。
其他回答
我有一个7GB的SQLite数据库。 使用内部连接执行特定查询需要2.6秒 为了加快速度，我尝试添加索引。根据我添加的索引，有时查询会下降到0.1秒，有时会上升到7秒。 我认为在我的情况下的问题是，如果一个列是高度重复的，然后添加索引降低性能:(
在SQLite文档中曾经有一个声明，数据库文件的实际大小限制是几十GB:s。这主要是因为当您启动事务时，SQLite需要“分配脏页面的位图”。因此，数据库中每MB需要256字节的RAM。插入一个50gb的db文件需要一个巨大的(2^8)*(2^10)=2^18=256 MB的RAM。
但是在SQLite的最新版本中，不再需要这样做了。点击这里阅读更多。
我在使用vacuum命令时遇到过大型sqlite文件的问题。
我还没有尝试auto_vacuum特性。如果您希望经常更新和删除数据，那么这值得一看。
我认为关于sqlite缩放的主要抱怨是:
单进程写。 没有镜像。 没有复制。
我们在我们的平台上使用的是50gb以上的DBS。没有抱怨很有效。 确保你做的每件事都是正确的!您是否使用预定义语句? * SQLITE 3.7.3
交易 预先发表的声明 应用这些设置(在创建DB之后) 编译指示主要。Page_size = 4096; 编译指示main.cache_size = 10000; 编译指示main.locking_mode =独家; 编译指示main.synchronous =正常; 编译指示main.journal_mode =细胞膜; 编译指示main.cache_size = 5000;
希望这将帮助其他人，在这里工作得很好
