Why we're ending support for MySQL
I mean, I'm not too upset that they're focusing on one DB engine, but their reasons are a bit facetious.> 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:> We can't support nested groups with MySQL in a performant wayAll they had to do was implement a nested set pattern for their groups [1]> We have to use hacks to increase limits on columns and this can lead to MySQL refusing to store dataA 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.> MySQL can't add TEXT type column without length specifiedThat'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.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!> MySQL doesn't support partial indexesThis is true, but is it really a show stopper?> As a side note – we don't use MySQL ourselvesI 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.[1] https://en.wikipedia.org/wiki/Nested_set_model