So far it seems more reliable than MySQL, as that system involves a client/server architecture that has dozens of points of failure. SQLite, via the code library, reads/writes directly to a single file (per database) meaning much less chance of failure. On a lot of MySQL backed sites, (penny arcade springs to mind) you'll often see MySQL errors pop up on their site when the database goes down, but not the webserver itself. No such thing for SQLite, as if the scripting engine is up, then so is the database. And since it's directly writing to a file, it's a lot quicker, and a lot easier to manage. You can just directly copy the file and have a full database backup, and from the point of an admin, you no longer have to manage an entirely seperate permission and quota set for the database server.
The drawback to SQLite is that since it does direct file access, you have no sort of transaction queueing or user permission levels. In place of transactions, it compensates with simple file locking, basically making processes queue for file write access, which works just fine in 99% of situations. I wouldn't try to use it for say, bank accounting when you have a hundred thousand transactions a second though. As for user permissions... it's not that it's insecure, it's simply a matter of permissions to the file itself. That is, anyone who can write to the file can write to the database. This really only becomes a problem if/when you need to set varying permissions to certain columns and tables. Of course, the best way to handle this is to have those permissions set and checked in the program's code, rather than the database engine. I personally think that's a better solution anyway, but it does mean that in such situations where a program relied on that functionality, it can't be just a drop-in replacement for MySQL.
