I ran a forum on SQLite for a few years before switching to Postgres fairly recently. This is not due to any shortcoming of SQLite, which I believe could have h

I ran a forum on SQLite for a few years before switching to Postgres fairly recently. This is not due to any shortcoming of SQLite, which I believe could have handled far more traffic than what we were already getting at the time (6K - 10K unique hits per day), but it allowed us to have nicer search features. I honestly don't know the upper limit of users you can support concurrently, but with modern hard drives, I imagine it's an order of magnitude beyond this. It has more to do with your application code than the database in my experience. I had an informal rule: Read early, write late. When the visitor first hits the page, I'll read for the first queries and only write to the database after I've sent the response back to the user. Writes are always the slowest, but no where near as slow as the network so the visitor never had to sit and wait for writes. The thing is, a lot of the criticisms of SQLite didn't actually apply if you limit the number of writes to < 10 and queries < 50 per hit and keep everything on one server. It's only when you try to write across the network a lot of the locking issues and such come up. Also, by 3.7, there was Write Ahead Logging (WAL) which was perfect timing as that allowed us to skip the DIY write queue entirely.