MySQL vs SQLite For Production Website?

[Michael Butash]

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.