Yeah. But if you're not publishing it to the entire world, you probably won't run into them. And there are many other applications where databases are useful, that aren't network servers of any kind.
Since the storage engine is a modified version of Tokyo Cabinet, I am assuming that you can have simultaneous readers, but a writer will lock everyone else out. From the Tokyo Cabinet specs [0]:
'Tokyo Cabinet provides two modes to connect to a database: "reader" and "writer". A reader can perform retrieving but neither storing nor deleting. A writer can perform all access methods. Exclusion control between processes is performed when connecting to a database by file locking. While a writer is connected to a database, neither readers nor writers can be connected. While a reader is connected to a database, other readers can be connect, but writers can not. According to this mechanism, data consistency is guaranteed with simultaneous connections in multitasking environment.'
I'd switch to a full DB server for a production Web App. If you're using an ORM it should be pretty trivial (the one time I've done it, Perl's DBIx::Class made it as easy as changing the connection info hash). I'm not sure how many people hand code their SQL at hackathons but I am not one of them ;).
I use SQLite in small and medium-traffic web apps (the largest one getting about 80000 hits daily) all the time with no concurrency issues whatsoever. My rule of thumb is that if you don't expect your app to require more than one server, sqlite will work just as fine as postgres or mysql.
For convenience mainly.. It saves me from having to install a "serious" RDBMS, import data, etc. With SQLite, deployment is simply copying the db file to the server.
