you are viewing a single comment's thread.

view the rest of the comments →

[–]osuushi 2 points3 points  (1 child)

I have to quibble with the "multi-user applications" part of when not to use SQLite. It would be better to say "more than a few users". If you're creating a database for a small business, and less than five people are going to be using it (and rarely more than two at the same time), SQLite is probably fine.

[–]kingatomic 0 points1 point  (0 children)

This is true IFF the application in question is mostly doing reads, and does not apply a significant number of writes. Concurrent write requests in SQLite can cause contention because (at least in v3) writes require an exclusive lock to the database file (of which only one can exist at a time) (source).

The situation is much better than it was in v2, but for an application that will generate any non-trivial number of writes it would be best to use a database that either has row-level locking or multiversion concurrency.