Consider also the redundancy aspect, expect drives to fail and things like that.  Do you want a production website down while you restore the os, reinstall everything, and presume to have an up to date backup of the db right before it died?  Rather have a copy on a partner replication slave a cluster can start feeding clients when the first dies.

Also consider if you're ever going to need to scale the website outside a monolithic single server, say with haproxy, dedicated hardware load-balancers, etc in front of mulitiple app servers. You need a way to scale data horizontally, maybe replicating between regions, replicating state of an in-use transaction (think shopping carts), etc.

SQLite is usually for a down/dirty local install of something that needs a db regardless of a real one or not, or used as local scratch for performance reasons.

-mb


On 05/28/2015 03:17 AM, Joseph Sinclair wrote:

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.

---------------------------------------------------
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