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 - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
