MySQL is a decent nosql option with mature replication. If you care about your data, expect MySQL to be your foe rather than your friend.<p>Do you expect your triggers to fire? You are SOL <a href="https://bugs.mysql.com/bug.php?id=11472" rel="nofollow">https://bugs.mysql.com/bug.php?id=11472</a><p>Do you expect to be able to insert utf8 into utf8 columns? Don't be naive. Read the docs and you'll discover utf8mb4 or as I like to refer to it: mysql_real_utf8.<p>How about transactions? Surely a real SQL database supports transactions right? Or at the very least if it doesn't it would complain loudly when you use a transaction where not supported right? Once again this behavior is helpfully documented <a href="https://dev.mysql.com/doc/refman/8.0/en/commit.html" rel="nofollow">https://dev.mysql.com/doc/refman/8.0/en/commit.html</a><p>Do you expect to be able to put a value into MySQL and get that same value back out? You are SOL. But it's documented.<p>I can honestly say that the only appropriate time to use MySQL is when you can't use postgres and you are willing to move from a RDBMS to something that requires significantly more work to prevent data corruption.<p>I respect the hell out of MySQL engineers in terms of raw performance and the engineering of Innodb. I'm sure they aren't happy there's a million broken applications relying on defaults they can't change. I'm sure they aren't happy that fundamental limits in how pluggable storage engines work make ACID transactions not possible in the general case.<p>Postgres, for all of it's issues, feels like a database that has your back.
I mean, I'm not too upset that they're focusing on one DB engine, but their reasons are a bit facetious.<p>> There are lots of great use cases for MySQL, our specific needs just didn't seem to be a good fit. Our use of MySQL had a number of limitations. In most cases, it wasn't as simple as adding support to MySQL, but that by bending MySQL we typically broke PostgreSQL. To name a few limitations:<p>> We can't support nested groups with MySQL in a performant way<p>All they had to do was implement a nested set pattern for their groups [1]<p>> We have to use hacks to increase limits on columns and this can lead to MySQL refusing to store data<p>A hack? Their DB creation schema specified a TEXT column when it should have been a LONGTEXT column. Using LONGTEXT is not a hack, it's a choice when your data is more than 65535 characters, and they made the wrong choice out of ignorance.<p>> MySQL can't add TEXT type column without length specified<p>That's just incorrect. What they MEANT to say is that they had a column to store filenames that was a varchar(255) column and people were running out of space with long directory paths and filenames. They could have moved to a TEXT column, but didn't because they thought it couldn't be indexed without specifying a length... But they were wrong, you CAN index a TEXT column without specifying the TEXT column length, you just have to specify the length of the substring you want to index.<p>Alternatively, since this is filepaths and filenames, they could have used a nested set pattern again and gotten 255 characters for each component of the path and a lot more feature options for their search system!<p>> MySQL doesn't support partial indexes<p>This is true, but is it really a show stopper?<p>> As a side note – we don't use MySQL ourselves<p>I think this is the real reason. They just didn't have the necessary talent to implement the features correctly. Wrong schema specifications and not knowing to implement nested set patterns is a sign that they don't have a knowledgeable DBA on staff.<p>[1] <a href="https://en.wikipedia.org/wiki/Nested_set_model" rel="nofollow">https://en.wikipedia.org/wiki/Nested_set_model</a>
All their more general points in the post are perfectly valid arguments for focusing on a single database that I've heard from other projects, but naming specific technical issues like that actually makes it seam more nit-picky and less valid.<p>I'm not sure many people would have found anything to argue with them about if they had simply said "Tagetting multiple DBs requires more resources to develop and test, limits our ability to make the most of what Postgres offers, and increases the cost of support. The proportion of users using MySQL is decreasing, so we have decided to focus on Postgres to give the maximum benefit to the largest group. We understand this may cause issues for some users so here is a comprehensive migration guide/toolset".
I remember like 10 years ago it was all the rage to support 45 different databases. I'm so glad that time has passed. It wasn't feasible. Yes you can orm the crap out of things so you never see a line of SQL but you end up with index tuning on multiple database platforms. I noticed the trend thankfully just sort of walked itself away about the time non-traditional databases entered the picture and well it was pretty much impossible to support Mongo and Mysql (reasonably). I'm assuming more things are going back to Mysql/Postgres/Sybase/DB2 again, but I hope more companies and OSS projects stick to just one this time?<p>The bottom line argument is this: When you make the decision to support multiple databases think of the 10-20 years of changes your product will exist through (and possibly a lot longer) and realize how much extra work that is going to be even if you use ORM. Then if you come to the decision Gitlab is - are you going to want to write the porting software for your users or just let them be shit-out-of-luck?
They just decided to use boring technology (<a href="http://boringtechnology.club/" rel="nofollow">http://boringtechnology.club/</a>). Given they have limited resource spreading it across two databases seems a miss, and taking that time and attention and putting it back into git-ty stuff looks like a win.
> MySQL can't add TEXT type column without length specified<p>Mysql does have a TEXT type with a max limit of 65536 chars (you can have MEDIUMTEXT or LONGTEXT if you want more).<p>You don't supply a length when you use TEXT<p><a href="https://dev.mysql.com/doc/refman/8.0/en/blob.html" rel="nofollow">https://dev.mysql.com/doc/refman/8.0/en/blob.html</a>
Good for them. Both MySQL and PostgreSQL are Good^. But supporting both doesn't work and it totally makes sense to focus on one. Personally, I don't generally use PGSQL but my GitLab instance does. Why? It's easy to run a dedicated PGSQL instance for GitLab using Docker. Or... Using AWS RDS. Or... Any number of ways.<p>(^ Good is relative. People have their opinions on which is subjectively better but at the end of the day, lots of big sites and applications use both options to great success.)
If you never used or heard of LATERAL [JOIN] I suggest checking that out because it is pretty awesome and handy.<p><a href="https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-LATERAL" rel="nofollow">https://www.postgresql.org/docs/current/queries-table-expres...</a>
I think here can be a good place to share my story why I never use MySQL in my projects. Once I was working for the company where I was an architect for some new project. And we have few gigabytes of data from a few sources. But with plans to gather much more in the near future. I came up with some database structure for the first draft of the early stage of development. It was nether big nether complicated for my scale comparing to the other projects I was working before. Since I'm python expert I choose SQLAlchemy for ORM layer and use its features to create the initial database schema. Postgres was a natural choice for me and almost fit to my requirements. I was worried about performance in the future but decided that we always can optimize when we have something. As I said it was early stage and we were on the research stage.<p>Everything was smooth development-wise but the database was pretty slow since we most use desktop-grade computers for prototyping. 3 weeks before the first internal release owners ask me to change the database to MySQL. I was against this step, we don't have time or resources for the experiments. But point was that company have MySQL experts that have more than 10 years of the optimization experience. I simply have no choice. They force me to do this against my will.<p>Since I wasn't sure that in production we will use Postgres I don't allow to use any special database dialect specific capabilities for the developers. And switching to another backend from Postgres to the MySQL was literally equal to a connection string change.<p>MySQL wasn't ready to handle 40-60 tables and queries with 5-10 simple joins. On our data, every request just hang server (they quickly provided a server with a lot of memory and storage for this). A few days later we found that actually MySQL is working but the same simple queries run for 4 or more hours. So-called "experts with 10 years of optimization" spent a week trying to fix indexes and other things but it never happened.<p>After release, I left the company, because of the toxic atmosphere, but it is another story. But since that, I lost all my faith in MySQL. Maybe for others, it is an option but never for me.
IMHO, this comes down to one thing. They lack the talent (and/or the will/resources to recruit it) to operate MySQL.<p>I can TOTALLY get the reasoning behind supporting only a single engine but the reasoning they write there are either wrong or misguiding.
I have used postgres for so long that a lot of the baked in functions and features that were super convenient for me.<p>I recall wanting to change a data type in my query and having to actually use the cast function. Also it was mentioned but when I was using it CTEs were not implemented yet. However, they weren't with postgres until 9.x as I recall either.<p>Regarding performance, I mean, that is as much design as it is rdbms choice. Also i'm no DBA.
Just look how slow gitlab is on a 8cpu with 32gb or ram instance ... It's crazy !
I'm not sure about which part is because of Rails or the way gitlab is implemented.
Issue is not about MySQL but more about the lack of knowledge / talent at gitlab
Doesn’t removing support for something violate breadth over depth?<p><a href="https://about.gitlab.com/company/strategy/#breadth-over-depth" rel="nofollow">https://about.gitlab.com/company/strategy/#breadth-over-dept...</a>