There could/can be cases to use SQLite over SQL Server, MySQL, Postgres, etc. It really comes down to reasoning with the problem. For me personally, I have onl

There could/can be cases to use SQLite over SQL Server, MySQL, Postgres, etc. It really comes down to reasoning with the problem. For me personally, I have only used SQLite for 2 scenarios. 1) When developing. SQLite is a simple method to getting something together, before building a proper MySQL/SQLServer/Postgres one. 2) Client software. Some client software needs a temporary data store and find SQLite great for this. These are not complicated databases. They barely have about 5 tables. Nothing more than a Queue system than anything, which goes over the wire via Rest API to a Messsaging Queue. Once sent over with a reply of "success" - it is removed from SQLite. It is a nice, simple system. There can be a few other reasons. Other than the above, I don't think I would be confident of SQLite file for a moderately sized database, likely to be used for some web portal or CMS system we created where more than one request could be talking to the database at the same time. This is why you should stick to those central, relational databases. MySQL and Postgres, especially, are not that difficult to install, whether on the same system or its own dedicated server. I hope my comment is not seen as a negative for SQLite. If anything, my attitude is the opposite. I really like the work and effort that has gone into SQLite. A virtual pat-on-the-back by those involved! It is a great approach to having data in 1 file, rather than writing your own.. or having lots of "records" in their own files (in a directory) which I have done.