SQLite数据库是中小站点CMS的最佳选择
SQLite 是一个类似Access的轻量级数据库系统，但是更小、更快、容量更大，并发更高。为什么说 SQLite 最适合做 CMS (内容管理系统)呢？并不是说其他数据库不好, Oracle、MySQL、SQLServer 也都是非常优秀的 DBS，只不过他们设计目标不同，特性不同，所以只有更适用某个应用场景，没有绝对的好坏之分。
我归纳的中小型站点的CMS的特点如下：
1、数据量不超过10万
2、日页面访问量不超过10万
3、 一部分网站全部生成静态页面，一部分网站实时查询数据库动态访问
4、 站长不懂技术，不懂得复杂的数据库维护，只会用 FTP 管理网站
5 、个人站点基本上是一个人管理，一般情况下只有一个人在访问后台，没有并发
6、 对数据库来说是读多写少，只有在站长访问后台的时候才会写入
7、 多运行于虚拟主机，大部分PHP主机均同时支持MySQL，小部分PHP主机需要单独购买MySQL，PHP+MySQL的主机价格较PHP主机价格高。 （以万网为例：最便宜的PHP空间780元，最便宜的PHP+MySQL的PHP空间1150元）
8、 多数中小站点的HTTP服务与MySQL部署在同一服务器上
SQLite 的优点在中小网站CMS应用场景下表现突出：
1、与MySQL相比，它更彻底的免费，并且没有任何使用上的限制
2、非常小巧，PHP5以上版本中无需任何配置即可支持SQLite
3、无需单独购买数据库服务，无服务器进程，配置成本为零
4、整个数据库存储在一个单个的文件中，数据导入导出备份恢复都是复制文件，维护难度为零
5、读速度快，在数据量不是很大的情况下速度较快，更重要的是：省掉了一次数据库远程链接没有复杂的权限验证， 打开就能操作
SQLite的缺点在中小网站 CMS 应用场景下被规避：
1、并发低 动态访问时当访问量不超过10万PV的时候，SQLite 超过 Access 的并发能力已经绰绰有余；生成静态页后更无需考虑数据库的并发问题
2、在大数据量的情况下表现较差 但是中小站点一般情况下数据量不超过10万，而SQlite 在 100 万数据量之下表现还不错，因为省掉了对数据库服务器的远程连接甚至会更快
3、写入较慢 默认配置下的 SQlite 的写入速度比MySQL慢了很多，但是 CMS 应用场景的写入操作较少。在插入新文章的时候基本感受不到慢。集中的写数据库操作只有在安装的时候会出现，不过只出现一次，可以忽略
4、为已有的表加索引较慢 但是在中小站点CMS中不会有这样的需求，可以忽略
5、无法将 MySQL 部署到与前端机不同的服务器上，但是中小站点也没 有分开部署的需求
综上所述：在中小站点 CMS 的应用场景下 SQLite 能最大限度的降低建站成本，降低维护难度，又很好得规避了自身的缺点。所以我认为未来支持 SQLite 的 CMS 系统一定会大行其道。
嵌入式数据库系统Berkeley DB
通常，我们在设计UNIX/LINUX平台下的应用软件时，如果数据种类繁多,数据与数据之间关系比较复杂，就会选用一些大型的企业级数据库系统，如 DB2，ORACLE、SYBASE等，如果软件规模不大，就倾向选用如MYSQL、POSTGRESQL等中小型数据库。例如使用PHP/PERL + MYSQL/POSTGRESQL设计网站基本上是一个很常规的做法。但是，当应用软件管理的数据类型较少（特别注意：这并不是说需要管理的数据量小）， 数据管理本身不复杂，且对数据操作要求高效率，则由大名鼎鼎的Berkeley（美国加州大学伯克利分校）开发的 Berkeley DB可能是一个很明智的选择。
DB 是一个具有工业强度的嵌入式数据库系统，数据处理的效率很高。DB功能的稳定性历经时间的考验，在大量应用程序中使用便是明证。可以想见，在同等代码质量 的条件下，软件的BUG数和代码的长度是成正比的，相对几十兆、几百兆大型数据库软件，DB的只有不到500K的大小！
从实现功能上看,DB是轻量级数据库系统，或可称为"极" 轻量级数据库系统。但是，我认为不能因此而心存轻视之意，所谓"尺有所短，寸有所长"，以绝对角度比较工具之间的好坏是没有什么意义的，关键在于对工具的 选择和运用（似乎可以参考一下极限编程的思想）。也许，正确的"表达范式"应该是：在当前应用背景下，选择这种工具是最合适的。
像MySQL这类基于C/S结构的关系型数据库系统虽然代表着目前数据库应用的主流，但却并不能满足所有应用场合的需要。有时我们需要的可能只是一个简单 的基于磁盘文件的数据库系统。这样不仅可以避免安装庞大的数据库服务器，而且还可以简化数据库应用程序的设计。Berkeley DB正是基于这样的思想提出来的。