They have to engineer their software for the highest-scale cases it’s going to be put to by people running it in a particular configuration. Just because Gitlab works without partial indexes for you doesn’t mean that Gitlab works without partial indexes for everyone, and software that doesn’t work for the 1% of users who use it most heavily (and probably pay GitLab the most money in support contracts) is also known as “software that doesn’t work.”
I don't think mySQL/MariaDB is particularly easier than PostgreSQL to setup for someone less familiar with them.
Every single time I've used mySQL, I come across some odd quirk from historical context. Limiting TEXT and creating LONGTEXT instead of increasing the bounds for TEXT. Keeping utf8 as some wierd non-final version of utf that isn't a spec, instead of aliasing it to the actual utf8 spec version in new configurations. Not sure if this is still an issue, not being able to create foreign key relationships with ansi-quoted table names (backticks only here). "BINARY" fields being collated as case invariant by default (led to some really bad bugs on a primary key field).
I can't think of a single time I've used mysql and didn't get odd behavior. I can't think of a single time I've used PostgreSQL, or even MS-SQL that I did. Oracle and DB2 have had some oddities as well, but at least consistent, unlike mysql.
MySQL is used in some of the largest scaled workloads and Postgres is just as easy to install and run today, if not easier.
With the huge rise in ready to run container images and managed database services, database ops is no longer a serious problem for small users and multiple DB choices shouldn't really be a major design consideration for software providers.
Yes, it works great. That article is very outdated. The official container images all store data and logs at configurable paths, and you can easily mount external volumes to those paths with docker or kubernetes. If these volumes are persistent disks in the cloud then you also get simple snapshotting and replication.
This is a great setup and effectively provides a database compute "shell" that sits on top of persistent block storage so backups and upgrades are simple to run. Add in orchestration like Kubernetes and you can also run replicas easily.
actually this is from 2016 and not true anymore..
you can easily run postgres/any database on k8s without any problems at all. heck you can even make it high available on gke with using replicated drives. (single instance of course, but with way less downtime. even gclouds db offerings are based on that)
Is that relevant outside of software that can run on random shared hosting? There being able to use MySQL is a large factor, but GitLab isn't in that category.
> they support mysql purely to make it easier for their smaller users to setup and manage instances.
That's not a real reason to support mysql, which is no more pleasant for non-DBAs to set up than any other traditional RDBMS. Rather, that's a reason to support sqlite. (See also, the reason sqlite is the default DB in Rails.)
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.
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
