John Nagle wrote: > [...] SQLite really > is a "lite" database. Although there's good read concurrency, multiple > updates from multiple processes tend to result in sizable delays, since > the locking is via file locks and wait/retry logic.
True, and I have other gripes about SQLite, but I've fallen in love with it. SQLite rocks. SQLite rocks like Python rocks. Hard as Python had rocked before, Python started rockin' a whole bunch harder when 2.5 included SQLite3 in the standard library. I love SQLite because it solves problems I actually have. For the vast majority of code I write, "lite" is a good thing, and lite as it is, SQLite can handle several transactions per second. I give SQLite a file path and in a split second I have a relational, transactional database. Great. I did not want to configure a server and I sure did not want to inflict complexity upon my users. If you are smart and/or lucky enough to write a web app so popular that it outgrows SQLite, you can switch over to a big-time SQL server DBMS. At worst, you'll have to tweak some of the code. Imagine how much harder the scaling problem would be if the persistent data were stored via pickle. The SQLite developers state the situation brilliantly at http://www.sqlite.org/whentouse.html: "SQLite is not designed to replace Oracle. It is designed to replace fopen()." -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list