I have to agree with Brian.  SQLite is not intended to replace a database, it's intended to replace a flat file.  Even the documentation for SQLite emphasizes that it replaces 'fopen()', not MySQL.
If you would be happy (from an admin perspective) keeping the entire data set in a single text file, then SQLite is probably a good choice (with better semantics!).
If you expect to *ever* need a "real" relational database backend, then start with MySQL (alt. MariaDB) or PostgreSQL (depending on use case and preferences) and evaluate from there.

On 05/27/2015 12:05 PM, Brian Cluff wrote:
> If your database is going to be fairly small it might be OK, but in my experience sqlite ground my website to a halt once the database had a few megs of data in it.  It really didn't take much data at all to become ridiculously slow.
> 
> Brian Cluff
> 
> On 05/27/2015 11:31 AM, Mark Phillips wrote:
>> I am working on a small project using the django framework. I have a
>> choice of backends - mysql, postgress, sqlite. The web site will have
>> low traffic, and 90% of the assets are scanned images (pdf, tiff, jpeg),
>> so they will be stored in a file system and not in the database. The
>> framework/database are for tags and search terms (ocr from pdfs) and
>> user login credentials.
>>
>> I am inclined to use the sqlite backend so the site uses fewer resources
>> and to make backups easier. However, I have never used sqlite in a
>> production environment. According to the sqlite website, it is
>> production ready.
>>
>> Would you recommend sqlite for a production website?
>>
>> Thanks,
>>
>> Mark
>>
>>