SQLite和C/S SQL数据库引擎没有直接的可比性，这些数据库引擎包括MySQL, Oracle, PostgreSQL, 或者 SQL Server，因为SQLite试图解决另外一个问题。

C/S SQL数据库引擎实现企业级数据共享，他们强调数据的可伸缩性，并发性，中心性和控制性；SQLite 为独立应用和设备提供本地化存储，它强调资源节约，高性能，可靠性，独立性和易用性。

SQLite不和C/S数据库引擎竞争，它的竞争对象是fopen() (Linux中打开文件的函数)![]

SQLite的完美应用场景嵌入式设备和物联网

因为SQLite不需要管理，在不需要数据库管理员支持的场景下工作良好，SQLite在下面这些设备中都有很好的应用：移动电话、机顶盒、电视机、游戏控制器、摄像机、智能手表、厨房电器、恒温控制器、汽车、机床、飞机、遥控器、遥控飞机、医疗器械还有机器人。

C/S数据库引擎被设计来放在核心网的数据中心，SQLite也可以这样做，而且在在网络边缘（可以理解为小型应用）的应用SQLite正在壮大。

应用程序文件

（理解为一些应用程序产生的文件里面其实包含了一个SQLite数据库） SQLite 经常被用来存放一些应用程序产生的文件的数据，例如版本控制系统、金融分析工具、剪辑套件的媒体目录、CAD文件包等等，一般用sqlite3_open()这个函数来打开数据库文件，当应用程序修改内容时会自动更新数据库，因此文件/保存按钮会显得有些多余。

网站（重点关注）

SQLite在小、中型流量的网站（绝大部分网站）上工作良好，SQLite 能够处理多少数据取决于网站有多少流量，通常来说，每天点击量在100K （10万）及以下的网站是没问题的，100K还是一个保守估计，不是一个硬上限，在实验中，SQLite 能够处理超过10倍的点击量（100k*10 = 100W）

SQLite官网就是用的SQLite，当然，在此篇文章写下之时(2015)，它每天要处理40W到50W的HTTP请求，其中有15~20%是需要连接数据库的（50W * 20% = 10W，刚好和作者上文说的数据相吻合）动态内容，动态内容使用了超过200句的SQL：，这个测试跑在和其他23个虚拟机共享一个物理机的环境中，仍然在大多数时间使其负载为0.1（这段话可以这么理解：作者用了一个200句SQL的测试跑在一个虚拟机上，每天10W的点击量，在大多数时候仍然保持较低的负载，说白了作者想用数据强调SQLite非常强大）。

数据分析

人们都知道SQL可以用来分析大量的数据集，SQLite有内置和一系列第三方的SQL命令行工具，数据可以从CSV文件中导入，数据可以被用来切片或切块，可以生成大量的摘要报告；一些复杂的分析可以用编程语言写简单的脚本，这些语言包括Tcl、Python（内置了对SQLite的支持）、R等语言，你可以用SQLite来分析网站访问日志、体育统计分析、实验结果分析。一些生物研究分析也使用的SQLite。

分析这件事情也可以使用C/S数据库，当然，使用SQLite的好处是它只是一个文件，可以随意拷贝，比如拷贝到U盘中，或者email给同事。

企业数据缓存

（理解为将C/S数据库中的数据缓存一部分到SQLite中） 一些应用会从关系型数据库中缓存一部分数据到本地（存储到SQLite中），这样可以减少延迟，因为大部分查询将在本地进行避免网络的双向损耗，这样也可以减少网络的负载，在大多数情况中，意味着在网络切断的情况下应用可以继续工作（因为数据都缓存到本地了嘛~~）

服务器端数据库

（理解为服务端底层用的是SQLite作为数据库引擎，然后提供给客户端数据，类似于C/S架构） 服务器端底层用SQLite作为数据库引擎。

在这种模式下，整个系统仍然是C/S架构:客户机发送请求给服务器，服务器通过网络返回数据，但是请求不是普通的SQL请求，返回的也不是原始的数据，客户端的请求和服务端的回复是一个高层次的，按照客户端需要来进行返回的。服务端将客户端的请求翻译成多条SQL语句进行过滤分析处理，然后构建高层次的结果返回。 （这段感觉和网站后台没有什么区别，就像一个页面有许多统计分析指标，请求发到服务器端，构建复杂查询一样）

数据传送

（SQLite单文件数据的优势） 因为SQLite是单个文件，兼容各个操作系统平台，它经常被用来作为数据传输，从一个系统到另一个系统。发送者只需要将数据导入进一个SQLite文件并将此文件传送给接受者，接受者用SQL提取需要的数据即可。

文件归档/数据容器

（可以理解为将文件打包进SQLite数据，类似于ZIP那种压缩文件一样吗，不过其优点主要是能进行实时更新） 更多参考!()

替换自定义数据文件

很多程序用fopen()，fread()，fwrite()创建自定义格式的数据文件，用SQLite来替换这些文件将会有更好的性能，一般来说，在读写文件时，SQLite比文件系统更快！

内存数据库或临时数据库

（理解为SQLite可作为内存数据库（具有快速，高效和临时性）） 内存数据库始终放在内存中，断电就消失，临时数据库会在磁盘产生文件，程序结束时消失，临时数据库也是常驻内存，当数据量大的时候会将一部分数据放到磁盘上，这是和内存数据库的最大区别。

在演示或者测试的时候代理C/S数据库

（说白了，SQLite是单文件，演示的时候方便拷贝...，一般在没网的时候可以这么干） 通常情况下，数据库编程都是面向接口的，底层数据库改变不影响程序逻辑，如JAVA的JDBC编程。将SQLite包含在受支持的数据库中，并静态地将SQLite引擎链接到客户机中，这是很有意义的。这样，客户端程序就可以单独使用SQLite数据文件进行测试或演示。

教育与培训

因为SQLite使用起来很简单，安装也很简单（只需要将 sqlite3 或者 sqlite3.exe可执行文件拷贝到目标机器上），简单易用，学生可以很简单的创建他们喜欢的数据库并且可以方便的email给他们的老师用来评论和评分。也可以作为学习关系型数据库的基础。

实验性SQL语言扩展

（可以理解为SQLite模块化的设计很简单，可以实验性的增加现有SQL语句没有的功能）

C/S关系型数据库引擎更加实用的场景C/S架构的应用

如果有很多客户端通过网络同时向服务器发送数据库查询请求，这种情况下用C/S数据库而非SQLite，因为网络有延迟，性能达不到最好，而且，许多操作系统（Unix和Windows都包含）的文件锁实现都有bug，如果文件锁错乱，并且此时有两个或者两个以上的客户端同时向数据库写内容，将会导致内容不一致，这是操作系统文件锁决定的，不是SQLite能解决的。

访问量巨大的网站

（大站有用SQLite？不可能的） 通常来说，SQLite可以作为网站服务器的后端，但是，如果是写密集型或者网站访问量很大的情况下，需要多个数据库服务器，那么考虑C/S数据库，而不是SQLite

数据量特别大

理论上来说SQLite支持最大单文件大小为128TB,但是许多文件系统都限制单个文件的大小，如果数据量特别大，还是考虑C/S数据库。

高并发

SQLite不限制并发读，但是每次只能有一次写，写的时候会上文件锁，在一些场景下，这不是个问题，因为吗，每一个写锁持续时间很短，不超过几十毫秒，但是有一些应用需要更好的并发性能，这就要考虑另外的解决方案了。

数据库选择正确与否检查表数据是否通过网络与应用程序分离？-->> 如果是，请选C/S数据库很多的并发写？-->> 如果是，请选C/S数据库数据量超大？-->> 如果是，请选C/S数据库其他情况? -->> 请选SQLite