It really is a matter of preference most of the time, but there are still some situations where one or the other has a significant advantage.

As one example:
PostgreSQL (and it's forks) has some high availability clustering support that isn't available currently for MySQL (and it's forks).
MySQL has some sharding support that isn't yet matched in the Postgres world.

There are certainly other areas where one or the other has a distinct advantage that cannot be cleanly matched, but it's not something I've spent a lot of time on.

On 05/27/2015 05:28 PM, Nathan England wrote:
> 
> I know very little about PostgreSQL so please forgive my ignorance. Your last statement caught my attention. You said to choose MySQL or PostgreSQL depending on use case and preferences. I can understand preferences because I would choose MariaDB because of familiarity, but what "use case" would you choose PostgreSQL over MySQL?
> 
> 
> 
> On 2015-05-27 14:53, Joseph Sinclair wrote:
>> 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
>>>>
>>>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>