Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Transactional DDL. If a database schema migration fails in MySQL, it has a nontrivial risk of leaving the database in a broken state that triggers a CAT-1 incident to restore site functionality. In PostgreSQL, such a failure simply results in the transaction being rolled back so the database is left in the state it was in before the migration attempt.

  • 1st-class Django support. Django has many useful features that only work with PostgreSQL, and many more cases where “this works on MySQL, but not as well as on PostgreSQL”. And this is a logical prioritization choice for the project’s maintainers - according to the 2022 JetBrains survey of Django developers, 79% of them work with PostgreSQL while only 28% use MySQL in any capacity.

  • Better full text search. MySQL comes with a rudimentary full text search engine, but the one in PostgreSQL is good enough to replace dedicated tools like Elasticsearch for many use cases (potentially including many Open edX installations).

  • Better JSON support. MySQL can store JSON data as text, but its ability to work with it as structured data is very limited. PostgreSQL does this well enough to outperform dedicated document databases like MongoDB in many use cases (potentially allowing yet another Open edX dependency to be dropped for many or all installations).

  • Better ecosystem of related software. As PostgreSQL has mostly surpassed MySQL in functionality and now in popularity, it’s becoming the first (and often only) database supported by an assortment of useful supporting software. (AWS is a notable exception for historical reasons.) For example:

  • Proper Unicode behavior. MySQL made the odd choice to make its default “utf8” encoding only support 3 of the 4 available bytes in the UTF-8 standard. The full 4-byte encoding was only added later as “utf8mb4”, and the default character set was still the much more restrictive latin1 until MySQL 8.0. This is forcing a difficult migration process to correct. The migration (and reasoning about Unicode behavior in MySQL in general) is complicated by the fact that MySQL has some hard-coded constraints involving index sizes, etc. that are defined in bytes instead of characters; trying to change the character encoding can fail depending on the content of indexed text fields.

  • Remove blocker to adoption. Organizations that are already strongly invested in PostgreSQL may be reluctant to use Open edX because it only works with MySQL.

  • More rapid development of new features. PostgreSQL is a pretty high-quality codebase under a liberal software license, and adds feature enhancements on a regular basis. MySQL was acquired by Oracle, which has a vested interest in upselling users to a much more expensive proprietary database product, so features which could reduce the incentive to upgrade are typically not added. This led to the creation of a fork called MariaDB, which served to further fragment and slow down development effort.

  • Developer Experience/Hiring/Retention. For many reasons like the ones noted above, PostgreSQL has become strongly preferred over MySQL by a solid majority of developers. StackOverflow’s 2023 developer survey notes that about 43% of developers would like to be working with PostgreSQL vs. only 24% for MySQL (and 71% of PostgreSQL users are happy with it, vs. only 51% for MySQL users). Consequently, despite MySQL’s early lead in popularity for historical reasons, PostgreSQL is now more widely used. (The MariaDB fork of MySQL fares even worse on most of these metrics.). This may not be a determining factor in software engineers deciding where to work, but it lands database selection solidly in the “con” column for many such decisions involving jobs involving Open edX and could help tip the scales one way or the other.

...

  • Community pressure. A significant percentage of the Open edX community may be reluctant to migrate from MySQL to PostgreSQL, especially if they already have significant in-house MySQL experience or use other software which only works with MySQL. We’d have to poll the community to gauge sentiment regarding this.

  • Fewer blockers to adoption. Organizations that have already invested heavily in MySQL might be more reluctant to adopt Open edX if it only works with PostgreSQL.