In my experience it is easier for the people not well versed in RDBMS administration to get MySQL going rather than postgres (this was always one of the adoption advantages). MySQL has also been easier to setup on any kind of server compared to postgres, and for features like replication. It is also true though that MySQL (at least up to 5.6/5.7) has plenty of limitations in implementations that really let you down at scale or in some cases (only one index per table per query across multiple tables, single threaded select, query planner has opaque view to how data is stored). The query planner being separate has been a boon in other places like mysql-ndb and rocksdb as storage engines but becomes a constraint you become increasingly aware of once yo get in the 0.3TB and up table club.

Sqlite is also an inappropriate database engine for any system that requires concurrent read/write access for multiple processes. While most people probably think they can work around this most people forget things like event logging and last checked timestamps which is a requirement for production applications.

I also want to mention that I did not read it in the comments here but I feel like MySQL and MariaDB still haven't settled their differences while postgres (to me) feels more stable. Then you also have the feature compatible DBaaS like AWS RDS. Also knowing you have PL/perl or PL/python in the back pocket seems hard to give up.

I mean, nobody uses sqlite for rails in production (except when they do because their load is genuinely low.) It's mostly there for when you're just running something for yourself on your own dev machine, most often for testing purposes. For something like this it makes a lot of sense to use sqlite. Avoid that in production though obviously.

From the sqlite docs: > SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites).

Oh, I know people do it. My point isn't that they should or shouldn't do it, but rather that supporting sqlite as a low-config option specifically to facilitate testing makes a lot of sense. Arguably more sense than continuing to support mysql when postgres exists.

I just have to say this, for me as a kid who grew up on Windows, installing MySQL was easier, it was also always available at all hosting providers, who also provided PHP to everyone.

To be fair, these days it might not be easier, for me user management was easier to understand.

Though these days I'm looking at Postgres and seeing only advantages: 1. Compliant 2. Not split into a billion versions 3. JSON