SQLite 的读写效率很高，有哪些使用其他数据库的理由？ - zzl0 的回答 - 知乎
https://www.zhihu.com/question/31417262/answer/881191147

SQLite 文档指出了什么时候用 client/server SQL 数据库（如 MySQL ）
1 、Is the data separated from the application by a network? → choose client/server
2 、Many concurrent writers? → choose client/server
3 、Big data? → choose client/server
4 、Otherwise → choose SQLite!

@perfectlife 主要是这团队里就我一个人会代码，别的地方要花的时间也不少。想先各个方面都搞到能跑起来。但又想心里有数什么时候就改换数据库了。

@mejee SQLite 就一个文件，暂时用 NAS 备份。MySQL 那些专业的方案我现在都没了解过啊。有什么博客或者链接推荐一下，我去了解了解吗？

@iseki 这是为啥呀？可以展开讲讲吗？

我觉得金融数据一股脑扔给 MySQL 也不行，时序数据的支持，关系数据库都比较那啥。

提高速度的关键在于自己分库分表，优化时间序列的索引方式。但说实话如果你能做到这一步，用 SQLite 你也能做。另一方面金融数据库一般很多时候会用来做实验，如果你能用 SQLite 解决这些事情，你天然多了一种在实验机器上本地缓存数据的方案，这样可以大大减轻你 MySQL 中央数据库的压力。

退一步你也可以使用 MySQL 中央数据库 + SQLite 本地缓存的模式。

不需要，SQLite 的性能其实很好。
之前测过单表两千万的库也就才 40G 的文件，性能一样可以接受。

而且备份极其简单，特别是你客户没有专业运维的时候，告诉他们下班停了程序文件复制一份就行了。

想要判断什么时候放弃，那就要想清楚你的程序的生命周期。在这个生命周期内，你打算支持多大量的数据，什么样的业务模式。
如果你的程序单机跑没法满足需求，那么可能数据库也要考虑替换。
如果你的程序单机足够满足需求了，没那么大负载也没有高可用需求，那么 SQLite 就是最好的选择。

另外，所谓安全性更不需要考虑。

当一个人可以物理访问到你的机器时，你就可以认为已经被公婆了。

从这方面考虑，SQLite 的安全性远超所有其它数据库。

更别说 SQLite 你可以加密数据文件，但其实意义不大。能接触到数据库文件，说明也能接触到你的程序文件，更别说你这还是服务器，挂个 debugger 连内存都能 dump 出来。这种情况下讨论安全配置没什么意义。

只要是单机版，SQLite 能吊打其他数据库，无论性能还是代码实现的容易程度

什么时候放弃用 SQLite ，那就是你放弃单机版的实现的时候

相对客观地说，这个世界大多数的应用都熬不过需要从 SQLite 转换到 MySQL 分库的时候

@janus77 对于 SQLite 而言，宿主语言也可以（甚至更好地）完成相同的任务吧？

还能更好应对分库分表，利用上 ORM ，减轻数据库压力等

好吧，就算存储过程是吧。还有啥嘛？