To be fair, you wouldn't need much more than SQLite to gather emails. It's more than sufficient (I would say it's absolutely amazing for most use cases, but the one thing I am not sure about is how well it handles concurrency, if at all).
I tried SQLite for a few things, and it has always come out a champ. I would not hesitate to use it for most of the semi-static websites I make (web apps would be pushing it), if I were sure it can handle more than one connection (I'm not, sadly).
I am very, very impressed by it. Seriously solid database.
SQLite is a file and thus uses file-level locking and does not have row-level locking. Data can not be read the same time anything is being written, so it is usually not great for multi-user applications or web applications.
Development, or 1-3 user web app it should perform OK. It doesn't scale and you will get db locks and retries if its under too much load.
To speed this up (if you must use SQLite), use a solid state drive as I/O performance is the biggest bottleneck.
actually it could use row-level locking since it uses row-oriented storage and fcntl locks can be applied to a set of bytes within a file. it could also do file-level locking on tempfiles with names derived from the table name and primary key of the row.
anyone with actual knowledge of it care to chime in with what it does do?
I have actual knowledge of it. The product I work on uses it as the production database because we distribute the software as a desktop application (and MySQL has licensing issues).
It COULD do row level locking, but it doesn't. SQLitening is the closest thing to performant SQLite you will get. And it only runs on Windows.
I tried SQLite for a few things, and it has always come out a champ. I would not hesitate to use it for most of the semi-static websites I make (web apps would be pushing it), if I were sure it can handle more than one connection (I'm not, sadly).
I am very, very impressed by it. Seriously solid database.