I use both PostgreSQL and SQLite in my job. I have mixed feelings about SQLite. If you play by its rules, it works very well, but I think you have to understand its rules well. If you do not set up your indexes correctly and do not use transactions correctly, performance can be horrible, but if you do, its performance is excellent. For some reason I doubt I will ever understand, its developer thinks that it is a good thing not to require a column to hold any particular type of information. One record can have an integer in a field, while the next record in the table can have a string in the same field. I would much rather have my database enforce type consistency, and tell me when I'm screwing up. There is no fixed date format. I suddenly found that one program that used SQLite began writing dates as human-readable text strings for no reason I could understand, after it had been writing them as Julian dates (a floating-point number representing the number of days since a given date) happily for years. I had to rewrite the corresponding program that reads the data to be able to handle either strings or Julian dates correctly and transparently, which was not easy.
But it is nice to have SQLite available for use in programs that will be installed at multiple customer sites where we can't be sure if the main database will be PostgreSQL, SQL Server, Oracle, or something else.
RobR
