关于SQLite的基础介绍本文就不再赘述，想要了解的请自行百度。接下来说一下一些使用经历。
SQLite数据库在一开始学习Flask的时候我就使用过，那时候用它是因为在Windows环境下搭建MySQL环境过于复杂，同时为了方便调试程序方便而折中采用了这个方案。
随着接触的东西变多，慢慢的更加认识到SQLite魅力所在。其实很多时候完全没必要上MySQL数据库，因为很多程序、网站实际的数据量并不多，而且是运行在单机环境下的。很多的小型网站、甚至是中型网站完全也可以采用SQLite作为数据库。
在搭建网站的时候，关于数据库可以有以下几种选项
我目前做的项目均是采用最后一种方式，因为这种方式可以一个数据库给多个后端应用程序调用。但如果是一个小型网站的话，完全可以采用第一种方式，既省钱（每个月60），又可以提升服务器的性能（减少一次数据库调用）。
数据量在10W以下，每日调用在10W次以下，都可以理解为小型网站。实际上数据量与调用次数提升10倍，SQLite数据库也是可以支撑的住。
同时在单机的情况下，可以少去搭建MySQL数据库的麻烦、减少服务器资源消耗。同时作为文件型数据库，操作起来非常方便，同时不会暴露端口也没有被黑客攻击的危险。
在做网站的时候，很多时候大家都会选择MySQL作为数据库，然后在大多数情况下，其实都可以使用SQLite代替MySQL，接下来我们就对比一下它们俩在做网站程序的差异。
在当你的网站不是很大时，完全可以采用SQLite代替MySQL。同时因为关系对象模型（ORM）的存在，在会使用MySQL的情况下，ORM工具完全可以抹平新技术的学习成本。
我一般是使用flask-SQLAlchemy开发Web程序，使用MySQL还是SQLite只要修改一下SQLAlchemy的数据库连接地址就可以实现自由切换。而对于数据库的操作，只要专注于模型的定义与方法的使用即可，一点儿也不用担心SQLite与MySQL之间的语法差异。
翻译不完整，更多详情请见原文。原文地址见附录。
SQLite不能直接与C/S架构的SQL数据库（如MySQL、Oracle、PostgreSQL或SQLServer）相比较，因为SQLite试图解决的是不同的问题。
C/S架构的数据库致力于实现数据的共享存储，它们强调可扩展性、并发性、集中化和控制。SQLite致力于为单个应用程序和设备提供本地数据存储。SQLite强调经济、效率、可靠性、独立性和简单性。
SQLite作为大多数中低流量网站的数据库引擎非常好用。SQLite能够处理的网络流量数量取决于网站对其数据库的使用程度。一般来说，任何一个点击率低于100K/天的站点都可以使用SQLite。10万点击量/天数是一个保守的估计，而不是一个硬上限。SQLite已经被证明可以处理10倍于此的流量。
因为SQLite数据库几乎不需要管理，因此对于那些无人值守运行或者无人工技术支持的设备，SQLite是一个很好的选择。SQLite非常适合运行在手机、机顶盒、电视、游戏机、照相机、厨房电器、恒温器、汽车、飞机、遥控器、无人机、医疗设备和机器人等物联网设备之中。
C/S架构的数据库就是为网络数据中心而精心设计。SQLite也可以运行在网络环境里面，并且在一些场景下蓬勃发展，为一些原本不可靠的连接提供数据服务。
SQLite通常作为桌面应用程序的本地磁盘文件格式，例如版本控制系统、金融财务分析工具、视频媒体编目和编辑套件、CAD包、记录保存程序等。
了解SQL的人可以使用SQLite命令行（或者第三方工具）来分析大量的数据。也可以从CSV文件导入原始数据，然后对这些数据进行处理，用来生成无数的简要报告。更复杂的分析也可以通过使用Tcl或者Python编写脚本，使用R语言或其他语言进行处理，大多数语言都已经适配了SQLite可以直接使用。可以完成的任务包含网站日志分析、体育统计分析、编程指标汇编和实验结果分析。许多生物信息学研究人员以这种方式使用SQLite。
当然，对于C/S架构的数据库也可以这样做。SQLite的优点是更容易安装和使用，并且生成的数据库是一个单独的文件，可以写入USB或通过电子邮件发送给同事。
系统设计人员报告称，成功地将SQLite用作数据中心中运行的服务器应用程序的数据存储，或者换句话说，使用SQLite作为特定于应用程序的数据库服务的底层存储引擎。
使用这种模式，整个系统仍然是C/S架构：客户端向服务器发送请求，并通过网络得到回复。但是，客户端请求和服务器响不是发送一般的SQL和获取原始表内容，而是高级的、特定于应用程序的指令（译者推测是类似RPC协议的东西）。服务器将请求转换为多个SQL查询，收集结果，进行后处理、筛选和分析，然后构造只包含基本信息的高级回复。
开发人员报告说，在这种情况下，SQLite通常比C/S架构数据库引擎更快。数据库请求是由服务器序列化的，因此并发性不是问题。并发性也通过“数据库分片”得到了改善：为不同的子域使用单独的数据库文件。例如，服务器可能为每个用户都有一个单独的SQLite数据库，这样服务器就可以处理数百或数千个同时连接，但每个SQLite数据库只能由一个连接使用。
如果你正在编写一个使用企业级数据库引擎的客户端程序，使用一个允许你连接不同SQL数据库引擎的通用型数据库后台将是很有意义的。这样，客户机程序就可以与SQLite数据文件独立使用，用于测试或演示。
一个很好的经验法则是，在同一数据库可以直接访问(没有中间的应用程序服务器)并且可以从网络上的多台计算机同时访问的情况下，避免使用SQLite。
SQLite作为网站的数据库后端，通常可以正常工作。但是，如果网站是读写密集型或者繁忙到需要多台服务器，那么可以考虑使用C/S架构数据库而不是SQLite。
SQLite数据库的大小限制为281TB(2的48次方字节，256tibibytes)。而且即使SQLite可以处理更大的数据库，它也会将整个数据库存储在一个磁盘文件中，而且许多文件系统将文件的最大大小限制在不超过这个值的地方。因此，如果您正在考虑这种规模的数据库，那么最好考虑使用一个C/S架构的数据库引擎，该引擎可以将其内容分散到多个磁盘文件中，也许还可以分散到多个卷中。
1、数据是否通过网络与应用程序分离→选择C/S架构数据库
关系数据库引擎起到减少带宽的数据过滤器的作用。因此，最好将数据库引擎和数据保持在同一个物理设备上，这样高带宽引擎到磁盘的链接就不必穿越网络，只需穿越低带宽应用程序到引擎的链接。
但是SQLite是内置在应用程序中的。因此，如果数据位于与应用程序分开的设备上，则需要跨网络的更高带宽引擎到磁盘的链路。这是有效的，但是不是最优的。因此，当数据位于与应用程序分离的设备上时，通常最好选择C/S架构的数据库引擎。
2、高并发写入→选择C/S架构数据库
如果许多线程和/或进程需要同时编写数据库(它们不能排队轮流编写)，那么最好选择支持这种功能的数据库引擎，这就意味着是C/S架构的数据库引擎。
3、大量的数据→选择C/S架构数据库
如果你的数据将增长到不适合或无法放入单个磁盘文件的大小，那么您应该选择SQLite以外的解决方案。SQLite支持最大281TB的数据库，前提是您可以找到支持281TB文件的磁盘驱动器和文件系统。即便如此，当内容的大小看起来可能会慢慢进入TB范围时，最好考虑一个集中的C/S结构的数据库。
4、否则→选择SQLite！
对于具有低并发性写入和少于1TB内容的设备本地存储，SQLite几乎总是一个更好的解决方案。SQLite快速可靠，不需要配置或维护。这样事情就简单多了。