增量和持续更新。当写入SQLite数据库文件时，只有文件中实际更改的部分才会写出到磁盘。这使得写入速度更快，并减少了固态硬盘的损耗。与定制和包装的文件堆格式相比，这是一个巨大的优势，这两种格式通常都需要写入整个文档才能更改单个字节。纯文件堆格式也可以在一定程度上执行增量更新，尽管使用文件堆格式(单个文件)写入的粒度通常比使用SQLite(单个页面)要大。SQLite还支持持续更新，不是在内存中收集更改，然后仅在File/Save操作中将其写入磁盘，而是可以在更改发生时将其写回磁盘。这样可以避免在系统崩溃或电源故障时丢失工作。使用触发器管理的自动撤消/重做堆栈可以保存在磁盘数据库中，这意味着可以跨会话边界执行撤消/重做。易于扩展。随着应用程序的增长，只需将新表添加到模式或将新列添加到现有表中，就可以将新功能添加到SQLite应用程序文件格式中。添加列或表不会改变先前查询的含义，因此只要稍微小心地确保保留遗留列和表的含义，就可以保持向后兼容性。当然，扩展自定义或文件堆格式也是可能的，但这样做通常要困难得多。如果添加了索引，则必须找到并修改更改对应表的所有应用程序代码，以使这些索引保持最新。如果添加了列，则必须定位并修改访问相应表的所有应用程序代码，以将新列考虑在内。性能：在许多情况下，SQLite应用程序文件格式比文件堆格式或自定义格式更快。除了原始读取和写入的速度更快之外，SQLite通常还可以显著缩短启动时间，因为应用程序无需读取整个文档并将其解析到内存中，而是查询只提取初始屏幕所需的信息。随着应用程序的进展，它只需要加载绘制下一个屏幕所需的材料，并且可以丢弃以前屏幕中不再使用的信息。这有助于控制应用程序的内存占用。文件堆格式可以像SQLite一样以增量方式读取，但许多开发人员惊讶地发现，SQLite可以从其数据库中读取和写入较小的BLOB(大小小于100KB)，速度比将这些BLOB作为独立于文件系统的文件进行读取或写入的速度更快。(有关详细信息，请参阅比文件系统和内部BLOB快35%，而不是外部BLOB。)操作关系数据库引擎会产生一些相关开销，但不应假设直接文件I/O快于SQLite数据库I/O，事实往往并非如此。在这两种情况下，如果SQLite应用程序中确实出现了性能问题，通常可以通过向模式中添加一条或两条CREATE INDEX语句或运行一次Analyze来解决这些问题，而无需接触一行应用程序代码。但是，如果以自定义或文件堆格式出现性能问题，修复通常需要对应用程序代码进行大量更改，以添加和维护新索引，或者使用不同的算法提取信息。由多个进程并发使用。SQLite自动协调从多个线程和/或进程对同一文件的并发访问。两个或多个应用程序可以同时连接并读取同一文档。写入是序列化的，但是由于写入通常只需要几毫秒，所以应用程序只需轮流写入。SQLite会自动确保文档的低级格式不会损坏。相比之下，使用自定义或文件堆格式实现同样的功能需要应用程序的广泛支持。而支持并发性所需的应用程序逻辑是臭名昭著的bug磁铁。多种编程语言尽管SQLite本身是用ANSI-C编写的，但是几乎所有你能想到的其他编程语言都有接口：C++、C#、Objective-C、Java、Tcl、Perl、Python、Ruby、Erlang、JavaScript等等。因此，程序员可以使用他们最熟悉的、最符合项目需求的任何语言进行开发。SQLite应用程序文件格式在有多个单独程序的情况下是一个很好的选择，这些程序通常使用不同的语言，由不同的开发团队编写。在研究或实验室环境中，通常会出现这种情况，其中一个团队负责数据获取，其他团队负责不同阶段的分析。每个团队都可以使用他们最熟悉的任何硬件、操作系统、编程语言和开发方法。