HTTP server + SQLite?

[Bryan]

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