WAL ( Write-Ahead Logging  预写式日志记录 ) 模式
　　3.7.0版本的SQLite添加了一个新的日志记录方法，使用预写日志记录。这本身不是什么真正值得兴奋的新闻，但这意味着对于 web应用（或任何并发机制）开发者来说，读者和作者不再相互限制。或者换个方式来说，读和写可以发生同时。如果没有有 WAL 模式，为了写这个数据库，作者将要求独占访问权，在撰写完成前，这个数据库无法被访问。
　　下面是一个例子来图解两者的不同，假设我们有两种进程状态，作者和读者。作者开始一个专有事务（表示有撰写的意图）。接下来，读者会开启一个事务，然后读者尝试去发布一个筛选的状态：
　　Journal mode = “delete” (the default):
　　Writer: BEGIN EXCLUSIVE
　　Reader: BEGIN
　　Reader: SELECT * FROM foo; Error: database is locked
　　Journal mode = “wal”:
　　Writer: BEGIN EXCLUSIVE
　　Reader: BEGIN
　　Reader: SELECT * FROM foo; Returns table contents
　　然而，值得注意的是，即使你不具有WAL模式，写通常发生在毫秒间。这是一个如此短的时间来让你注意到问题，如果你有非常高的并发或有很长的事务要写。
　　额外的原因：BerkeleyDB
　　BerkeleyDB的SQLite的整合甚至可以给需要访问并发数据库的应用程序开发者们提供更好的性能，因为BerkeleyDB不是锁定整个数据库，而是只需要锁定单个页面。这使得BerkeleyDB在加载并发数据库时有更高的吞吐量，只要事务没有争夺同一页数据。BerkeleyDB还支持多版本并发控制（MVCC），它允许读的操作继续发生在正在运作写的事务的数据页。
　　BerkeleyDB另一个好处是效率的提高。换句话说，BerkeleyDB可以使用更少的系统资源和执行更少的系统调用。你可以在这份白皮书和简要技术概述中找到更多的细节。
　　BerkeleyDB的SQL接口是SQLite的一个插入式替换方式，并支持相同的APIs和功能。BerkeleyDB提供了一些附加功能，比如复制（SQLite有备份实用工具，但我的理解是，它不如BDB强大）、加密，当然还有包括BerkeleyDB自身所有的功能。
　　BerkeleyDB使用起来的一大缺点是对配置值非常敏感，并且获取正确的页面大小、缓存大小等其他设置需要深厚的知识。另一个缺点是授权许可——阅读更多关于BerkeleyDB的授权许可，可查看Oracle的授权页面。
　　关于编译使用BerkeleyDB编译Python SQLite驱动的操作指南，可以看看这个帖子。
　　结束语
　　我希望你可以试一试SQLite 。不要相信FUD（Fear，Uncertainty，Doubt，一种别有用心的打击手段）对它的描述：没有生产价值，或者不适合在web应用上使用。