> All they had to do was implement a nested set pattern for their groups

The nested set pattern was considered at the time we added support for nested groups, or improved it with CTEs (not sure which one of the two it was). The biggest drawback of nested sets is that adding sub groups can now become expensive. The storage needs are also far from ideal.

Using PostgreSQL CTEs allowed us to work around all of this, at the cost of not supporting MySQL. This seems like a fairly reasonable trade-off, but I might be biased as I implemented it [1].

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

It's not ignorance, it's MySQL coming up with bizarre limits for the "TEXT" type. In MySQL, the limit for TEXT is 64 KB. In PostgreSQL, IIRC it is 1 GB. Looking back there may have been better decisions, but it's always easy to judge in hindsight.

More importantly, moving away from MySQL allows us to stop worrying about this at all.

    > 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!

At the cost of requiring more storage space, and writes taking (potentially) much longer. You may want to mention that, instead of acting as if nested sets are a silver bullet.

    > This is true, but is it really a show stopper?

Yes.

    > Wrong schema specifications and not knowing to implement nested set
    > patterns is a sign that they don't have a knowledgeable DBA on staff.

You may want to do some more research before going down the path of suggesting GitLab employees lack knowledge. For the last two years or so we've had various engineers with excellent database knowledge working on GitLab, myself included (though I don't consider myself a PostgreSQL expert).

Some of the weirder decisions were made before the right people were hired, and often these decisions are difficult to improve upon. Sometimes removing support for something is a much more efficient way of spending your time. Removing MySQL support in GitLab is one such case.

[1]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10885