Small. Fast. Reliable.
Choose any three.
Choose any three.
由于SQLite试图解决其他问题，因此SQLite无法直接与诸如MySQL，Oracle，PostgreSQL或SQL Server之类的客户端/服务器SQL数据库引擎进行比较。
客户端/服务器SQL数据库引擎努力实现企业数据的共享存储库。他们强调可伸缩性，并发性，集中性和控制性。SQLite致力于为单个应用程序和设备提供本地数据存储。SQLite强调经济，效率，可靠性，独立性和简单性。
SQLite不与客户端/服务器数据库竞争。SQLite与fopen（）竞争。
由于SQLite数据库不需要管理，因此可以在必须在没有专家人工支持的情况下运行的设备中很好地工作。SQLite非常适合用于手机，机顶盒，电视，游戏机，照相机，手表，厨房用具，恒温器，汽车，机床，飞机，远程传感器，无人机，医疗设备和机器人：东西的”。
客户端/服务器数据库引擎被设计为位于网络核心的精心照料的数据中心内。SQLite也可以在这里工作，但是SQLite也可以在网络边缘蓬勃发展，为自己提供保护，同时为本应具有狡猾的连接性的应用程序提供快速，可靠的数据服务。
申请文件格式
SQLite通常用作桌面应用程序的磁盘文件格式，例如版本控制系统，财务分析工具，媒体编目和编辑套件，CAD软件包，记录保存程序等。传统的“文件/打开”操作调用sqlite3_open（）附加到数据库文件。在修改应用程序内容时，更新会自动发生，因此“文件/保存”菜单选项将变得多余。可以使用备份API来实现File / Save_As菜单选项。
这种方法有很多好处，包括改进的性能，降低的成本和复杂性以及改进的可靠性。有关更多信息，请参见技术说明 “ aff_short.html”和 “ appfileformat.html”和 “ fasterthanfs.html”。该用例与下面的数据传输格式和 数据容器用例密切相关 。
网站
对于大多数中低流量的网站（也就是说，大多数网站），SQLite可以很好地用作数据库引擎。SQLite可以处理的网络流量取决于网站使用其数据库的程度。一般来说，任何每天点击量少于10万的网站都可以在SQLite上正常运行。每天10万次点击是一个保守的估计，而不是一个硬上限。SQLite已被证明可以处理10倍的流量。
SQLite网站（https://www.sqlite.org/）当然使用SQLite本身，截至撰写本文（2015）时，它每天处理约40万至500K HTTP请求，其中约15-20％是动态的页面接触数据库。每个网页的动态内容使用大约200条SQL语句。此设置在单个VM上运行，该VM与23个VM共享一台物理服务器，但大多数情况下仍将平均负载保持在0.1以下。
数据分析
懂SQL的人可以使用 sqlite3命令行外壳程序（或各种第三方SQLite访问程序）来分析大型数据集。可以从CSV文件导入原始数据，然后可以对该数据进行切片和切块以生成大量的摘要报告。可以使用以Tcl或Python（两者均内置SQLite）或以R或其他语言编写的简单脚本（使用现成的适配器）进行更复杂的分析。可能的用途包括网站日志分析，体育统计分析，编制编程指标以及分析实验结果。许多生物信息学研究人员以这种方式使用SQLite。
当然，使用企业客户端/服务器数据库可以完成相同的操作。SQLite的优点是易于安装和使用，并且生成的数据库是单个文件，可以将其写入USB记忆棒或通过电子邮件发送给同事。
缓存企业数据
许多应用程序使用SQLite作为来自企业RDBMS的相关内容的缓存。这减少了等待时间，因为现在大多数查询都是针对本地缓存进行的，并且避免了网络往返。它还减少了网络和中央数据库服务器上的负载。而且在许多情况下，这意味着客户端应用程序可以在网络中断期间继续运行。
服务器端数据库
系统设计人员报告说，使用SQLite作为在数据中心中运行的服务器应用程序上的数据存储，或者换句话说，使用SQLite作为特定于应用程序的数据库服务器的基础存储引擎，已经取得了成功。
在这种模式下，整个系统仍然是客户端/服务器：客户端将请求发送到服务器，并通过网络获得回复。但是，客户端请求和服务器响应不是高层SQL而是特定于应用程序，而不是发送通用SQL并获取原始表内容。服务器将请求转换为多个SQL查询，收集结果，进行后处理，过滤和分析，然后构造仅包含基本信息的高级答复。
开发人员报告说，在这种情况下，SQLite通常比客户端/服务器SQL数据库引擎更快。数据库请求由服务器序列化，因此并发不是问题。通过“数据库分片”还可以提高并发性：对不同的子域使用单独的数据库文件。例如，服务器可能为每个用户有一个单独的SQLite数据库，因此服务器可以处理数百或数千个同时连接，但是每个SQLite数据库仅由一个连接使用。
资料传输格式
由于SQLite数据库是具有定义良好的跨平台格式的单个压缩文件 ，因此它通常用作将内容从一个系统传输到另一个系统的容器。发送者将内容收集到一个SQLite数据库文件中，将该文件传输到接收者，然后接收者根据需要使用SQL提取内容。
即使端点具有不同的字长和/或字节顺序，SQLite数据库也有助于在系统之间进行数据传输。数据可以是大型二进制Blob，文本以及小型数值或布尔值的复杂组合。通过添加新表和/或列，可以轻松扩展数据格式，而不会破坏传统的接收器。SQL查询语言意味着不需要接收者立即解析整个传输，而是可以根据需要查询接收到的内容。数据格式是“透明的”，即可以使用多家供应商提供的各种通用开放源代码工具轻松解码以供人类查看。
文件档案和/或数据容器
在SQLite的归档想法节目的SQLite如何被用作ZIP压缩文件或压缩包的替代品。与等效的ZIP存档相比，存储在SQLite中的文件存档仅稍大一些，在某些情况下实际上较小。SQLite存档具有增量和原子更新功能，并具有存储更丰富的元数据的功能。
除传统的tarball和ZIP存档外，Fossil 2.5版及更高版本还提供 SQLite存档文件作为下载格式。该sqlite3.exe命令行外壳版本3.22.0和以后将创建，列表或解压的SQL使用存档 .ARCHIVE命令。
对于需要将各种内容捆绑到一个自包含且自描述的程序包中以通过网络进行传送的情况，SQLite是一个很好的解决方案。内容以定义良好，跨平台且稳定的文件格式编码 。编码效率很高，接收者可以提取内容的小子集，而不必读取和解析整个文件。
SQL存档可用作分发给许多客户端的软件或内容更新的分发格式。例如，使用此想法的变体将电视节目指南传输到机顶盒，并将空中更新内容发送到车辆导航系统。
临时磁盘文件的替换
许多程序使用 fopen（）， fread（）和 fwrite（）来创建和管理本地格式的数据文件。SQLite可以很好地替代这些临时数据文件。与直觉相反，SQLite 在读取和写入磁盘内容方面可能比文件系统快。
内部或临时数据库
对于必须以多种方式进行筛选和排序的大量数据的程序，将数据加载到内存中的SQLite数据库中并使用带有join和ORDER BY子句的查询来提取数据通常更容易，更快捷。所需的形式和顺序，而不是尝试手动编码相同的操作。以这种方式在内部使用SQL数据库还为程序提供了更大的灵活性，因为可以添加新的列和索引而不必重新编码每个查询。
在演示或测试期间替代企业数据库
客户端应用程序通常使用通用数据库接口，该接口允许连接到各种SQL数据库引擎。将SQLite包含在受支持的数据库中并与客户端静态链接SQLite引擎是很有意义的。这样，客户端程序可以与SQLite数据文件一起单独使用以进行测试或演示。
教育和培训
因为它易于设置和使用（安装很简单：只需将sqlite3或sqlite3.exe可执行文件复制到目标计算机上并运行它），SQLite成为了一个很好的数据库引擎，可用于教授SQL。学生可以轻松地创建任意数量的数据库，并可以通过电子邮件将数据库发送给教师以进行评论或评分。对于对研究RDBMS的实现方式感兴趣的更高级的学生，模块化的，注释明确的和记录在案的SQLite代码可以作为一个良好的基础。
实验性SQL语言扩展
SQLite的简单模块化设计使其成为用于对新的实验性数据库语言功能或思想进行原型设计的良好平台。
客户端/服务器应用程序
如果有许多客户端程序通过网络将SQL发送到同一数据库，请使用客户端/服务器数据库引擎而不是SQLite。SQLite将在网络文件系统上工作，但是由于与大多数网络文件系统相关的延迟，性能不会很好。而且，文件锁定逻辑在许多网络文件系统实现中（在Unix和Windows上）都是错误的。如果文件锁定无法正常工作，则两个或多个客户端可能会尝试同时修改同一数据库的同一部分，从而导致损坏。由于此问题是由底层文件系统实现中的错误引起的，因此SQLite无法采取任何措施来阻止它。
一条好的经验法则是避免在直接通过网络访问同一数据库（而无需中间应用程序服务器）并且同时从多台计算机同时访问同一数据库的情况下使用SQLite。
大量网站
SQLite通常可以作为网站的数据库后端正常运行。但是，如果该网站写密集型网站或非常繁忙以至于需要多个服务器，则可以考虑使用企业级客户端/服务器数据库引擎而不是SQLite。
大型数据集
SQLite数据库的大小限制为281 TB（2 48字节，256 TB）。即使可以处理更大的数据库，SQLite也会将整个数据库存储在一个磁盘文件中，许多文件系统将文件的最大大小限制为小于此大小。因此，如果您正在考虑这种规模的数据库，那么最好考虑使用一种客户机/服务器数据库引擎，该引擎将其内容分布在多个磁盘文件中，甚至可能分布在多个卷中。
高并发
SQLite支持无限数量的同时读取器，但是在任何时间都只能允许一个写入器。在许多情况下，这不是问题。作家排队。每个应用程序都会快速完成其数据库的工作并继续运行，并且锁定不会持续超过几十毫秒。但是有些应用程序需要更多的并发性，而这些应用程序可能需要寻求不同的解决方案。
数据是否通过网络与应用程序分开？→选择客户端/服务器
关系数据库引擎充当减少带宽的数据过滤器。因此，最好将数据库引擎和数据保留在同一物理设备上，以使高带宽的引擎到磁盘的链接不必遍历网络，而仅需较低带宽的应用程序到引擎的链接。
但是SQLite内置在应用程序中。因此，如果数据与应用程序位于不同的设备上，则要求更高带宽的引擎到磁盘的链接跨网络。这行得通，但不是最佳选择。因此，通常最好在数据与应用程序位于不同设备上时选择客户端/服务器数据库引擎。
注意： 在此规则中，“应用程序”是指发出SQL语句的代码。如果“应用程序”是应用程序服务器，并且内容与应用程序服务器位于同一台物理计算机上，那么即使最终用户离另一个网络跳远，SQLite仍然可能适用。
并发作家很多？→选择客户端/服务器
如果许多线程和/或进程需要同时写入数据库（它们无法排队并轮流使用），那么最好选择一个支持该功能的数据库引擎，这始终意味着客户机/服务器数据库引擎。
SQLite每个数据库文件一次仅支持一个编写器。但是在大多数情况下，一次写事务只需要毫秒，因此多个写者可以简单地轮流执行。SQLite将处理许多人怀疑的更多写入并发。尽管如此，客户端/服务器数据库系统由于手头有一个运行时间较长的服务器进程来协调访问，因此通常可以比SQLite处理更多的写并发。
大数据？→选择客户端/服务器
如果您的数据增长到您不舒服或无法放入单个磁盘文件的大小，则应选择SQLite以外的解决方案。假定您可以找到支持281 TB文件的磁盘驱动器和文件系统，SQLite支持的数据库最大为281 TB。即使这样，当内容的大小看起来可能会达到TB范围时，最好考虑使用集中式的客户端/服务器数据库。
否则→选择SQLite！
对于编写者并发性较低且内容少于1 TB的设备本地存储，SQLite几乎总是一个更好的解决方案。SQLite快速可靠，无需配置或维护。它使事情变得简单。SQLite“行之有效”。