5 ms·

"Mysql can not scale to higher usage and is not supported for those workloads" Nobody supports mysql for scaling workloads. they support mysql purely to make i

"Mysql can not scale to higher usage and is not supported for those workloads" Nobody supports mysql for scaling workloads. they support mysql purely to make it easier for their smaller users to setup and manage instances.

deleted 7y ago
[deleted]
detaro 7y ago
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.
tracker1 7y ago
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.
darkpuma 7y ago
> 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.)
- xemdetia 7y ago
  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.
  - darkpuma 7y ago
    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.
    - taffer 7y ago
      From the sqlite docs: > SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites).
      - darkpuma 7y ago
manigandham 7y ago
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.
- bradknowles 7y ago
  So, you're running your databases in containers? Really? Have you read "Thou Shalt Not Run a Database Inside of a Container"? See https://patrobinson.github.io/2016/11/07/thou-shalt-not-run-a-database-inside-a-container/ https://patrobinson.github.io/2016/11/07/thou-shalt-not-run-...
  - merb 7y ago
    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)
  - manigandham 7y ago
    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.

deleted 7y ago

[deleted]

detaro 7y ago

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.

tracker1 7y ago

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.

darkpuma 7y ago

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

xemdetia 7y ago
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.
- darkpuma 7y ago
  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.
  - taffer 7y ago
    From the sqlite docs: > SQLite works great as the database engine for most low to medium traffic websites (which is to say, most websites).
    - darkpuma 7y ago

manigandham 7y ago

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.

bradknowles 7y ago
So, you're running your databases in containers? Really? Have you read "Thou Shalt Not Run a Database Inside of a Container"? See https://patrobinson.github.io/2016/11/07/thou-shalt-not-run-a-database-inside-a-container/ https://patrobinson.github.io/2016/11/07/thou-shalt-not-run-...
- merb 7y ago
  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)
- manigandham 7y ago
  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.