Schema change release: May 15, 2023

MusicBrainz is announcing a new schema change release for May 15, 2023. The actual schema (database) changes we’ve detailed below shouldn’t have much perceivable impact on mirror servers, especially if you only use the web service; most are to remove unused tables/columns or tweak how certain tables are materialized.

The only breaking change to a replicated table is dropping the cdtoc.degraded column (MBS-12573). It’s unused in our codebase, so will have no effect on the web service. However, if you’re querying the cdtoc table directly, you’ll want to make sure your SQL queries don’t expect this column to exist.

One minor change affects first-release-date data for release groups and recordings in the web service (MBS-12800), but only where cancelled releases exist. As of this writing, there are currently only 133 releases with the “cancelled” status.

One change we consider significant is that, as part of this release, we plan to enable replication with dbmirror2 (MBS-12107) by default. This should require no changes on the part of mirror server operators and should be completely invisible/seamless during the upgrade if all goes according to plan. We consider it significant because it’s rewriting a critical part of our replication system and changing the packet format used underneath.

Tools that operate on the current (let’s call them version 1) replication packets, like mbdata, will continue to work; MusicBrainz will continue to generate the old  v1 packets for the foreseeable future while we work to move external tools to the new, v2 packet format.

Read more: Schema change release: May 15, 2023

Without further introduction, here’s the list of tickets for the Spring 2023 schema change:

Schema changes

The following tickets change the database schema in some way.

  • MBS-4685: Allow removing own edit notes when there’s been no follow-up / MBS-11312: Allow original editors and admins to modify edit notes. In order to give editors and admins the option to modify or delete edit notes, this will add a new (non-replicated) table, edit_note_change, where the information about any changes made will be stored. No changes will be made to the structure of the existing edit_note table.
  • MBS-12573: Drop unused degraded column from cdtoc. This was a column that was used many years ago to store whether CD TOCs were based on a less accurate algorithm. For a long time, it’s always contained FALSE (since we dropped the less accurate data at some point). It’s also completely unused. We are just dropping the column entirely.
  • MBS-12704: Remove legacy “Watch artist” code. Over 10 years ago, we had code to follow artists and be notified of new releases and whatnot, but the whole system was never upgraded during the NGS migration. We have decided that if we re-implement this, it will be as part of ListenBrainz, not MusicBrainz. As such, we are dropping the relevant tables: editor_watch_artist, editor_watch_preferences, editor_watch_release_group_type, editor_watch_release_status.
  • MBS-12794: Don’t use spammer tags/ratings when calculating tag counts / rating averages. We do not delete spammer accounts (we just hide them) in order to train our code to identify other potential spammers. An unfortunate side effect of this is that any ratings and tags left by spammers are currently still taken into account when calculating aggregate ratings and tags for MusicBrainz entities. We’ll be making a change to our triggers that update these aggregates to ignore any ratings and tags by editors marked as spammers. This change affects master/standalone databases, but should have no impact on mirror servers, where these triggers do not exist. Some tag and rating values will be changed by this though.
    Edit (Mar. 23): The team has removed MBS-12794 from this release after deciding that the implementation needs more discussion.
  • MBS-12800: Exclude cancelled releases when calculating first recording / release group dates. We store data about releases which were announced, but then were cancelled before they were released. These are often stored with release dates, representing the date the release was meant to have been released. While this makes sense, it has the side effect that these dates affect the calculation of the first release date for any recordings linked to these releases, and the release groups they are in. Clearly, the recordings and release groups were not released on these dates, and we should use the date of their first actual release instead. This will change the triggers that update the release_first_release_date materialized table, which itself will affect the calculations of recording_first_release_date and the release date columns in release_group_meta. These triggers run on mirrors as well.

The remaining tickets below do not make any changes to the database schema.

Replication system changes

  • MBS-12107: Replication with dbmirror2. See the introduction above and the linked ticket for more information. The prerequisite database changes required for this were already applied as part of the Spring 2022 schema change, so enabling the v2 system only requires code changes.

Upgrade script changes

  • MBS-12370: Rename schema change upgrade script suffixes to clearly indicate which nodes they run on. This is an internal-only change which should have no impact on users.

We’ll post upgrade instructions for standalone/mirror servers on the day of the release. If you have any questions, feel free to comment below or on the relevant JIRA tickets.

Steps to fix missing genre and tag data on MusicBrainz mirror servers

If you recently updated your mirror server to the 2022-05-16 schema change release, we’re sorry to say that a bug in our upgrade script caused aggregate genre and tag data (if you had imported any) to be deleted. If you need this data, it can be re-imported from a recent dump, and we’ve written a script to help automate that.

You can safely ignore this post if

To restore the genre and tag data, follow these steps:

  1. Ensure you’ve replicated up to the most recent replication packet available. If you’re not sure, run ./admin/replication/LoadReplicationChanges. If you’re up-to-date, it should log “Replication packet … is not available.”
  2. Run git checkout production && git pull origin production.
  3. Turn off any cron jobs that update the database, including for replication.
  4. Run ./admin/sql/updates/
  5. Restart any cron jobs that you disabled.

You can verify that this process worked by checking the number of tags in the database: echo 'SELECT count(*) FROM tag' | ./admin/psql READWRITE. It should be over 200,000.

Sorry for the inconvenience, and let us know if you encounter any further issues.

Schema change release: May 16, 2022

Today we’re announcing a MusicBrainz database schema change release planned for May 16, 2022. The majority of these changes follow the theme of improving data integrity and consistency, performance, or just cleaning up old cruft. Others relate to new features for genres and artist credits. We’re also introducing a new entity based on tags, like genres that came before it: Mood. See below for more details, including information on how these changes affect the schema or existing data. We expect people will encounter zero breaking changes, but it doesn’t hurt to double check, especially if you have a specific or non-standard use of the database!

Here’s our list of tickets for the Spring 2022 schema change:

Schema changes

  • MBS-12256: Keep rating and rating_count column on *_meta tables up-to-date with triggers. An internal-only change to help us keep aggregate rating information (i.e. an average rating and count of ratings for each entity) up-to-date more easily, and help keep these values accurate. This change affects master/standalone databases, but should have no impact on mirror servers, where such triggers are not created. It’s possible that some existing aggregate ratings data was out of sync and will be updated with this change.
  • MBS-12224: Keep tags’ ref_count and aggregate vote counts updated with triggers. Like the change above for ratings, this is primarily internal-only and intended to help us keep tag counts in sync, though an adjacent goal is to make features like MBS-960 easier to implement. This also revives the tag.ref_count column, which hasn’t been updated for years, in order to provide a faster way of sorting tags/genres by usage count. Like above, this change should have no impact on mirror servers schema-wise, but will fix some existing corrupt tag counts.
  • MBS-12249: Add a materialized area_containment table kept up-to-date with triggers. Pages that make use of area containments, e.g. the list of artists from an area, which are expected to account for sub-areas, are currently quite slow and we’d like to improve upon this. The slowness is related to the recursive queries we use to get contained sub-areas – these queries are uncached and calculated on-the-fly. This ticket addresses these performance issues by caching area containment information in a new aptly-named area_containment table. Consistent with the tag and rating tickets above, this table will also be kept up-to-date with triggers. This change should have no impact on mirror servers except to make certain area requests faster; it does not affect existing data.
  • MBS-12250: Create dbmirror2 schema on production and mirror servers. The dbmirror extension we use to generate our replication packets a.k.a Live Data Feed is a 20 year old tool. It has issues and limitations that are difficult to fix, and we aim to replace it with something more maintainable. We wrote dbmirror2 to do that, but still have the task of getting it deployed to mirrors seamlessly. This will happen invisibly without any changes needed on mirrors! The action for this ticket is to simply create the schema for dbmirror2; it’s not actually used for replication yet. We’ll first have a testing phase and make sure external projects like mbdata work with the new replication packet format.
  • MBS-12200: Drop schema objects related to Amazon cover art support. For a long while, releases with Amazon URLs would be checked for cover art on Amazon, and if found, a link to the image would be cached for display. Unfortunately Amazon’s API to do this changed, and we haven’t synced artwork from them in years. We still have many old images cached and we still display those, but they aren’t guaranteed to be in sync. Last year we decided to drop support for displaying these, while giving time for users to upload any correct images to the Cover Art Archive. To help with this, we have a report of releases with Amazon cover art but no Cover Art Archive front cover.

    The schema change here involves dropping the release_coverart table (which was private and non-replicated) and the release_meta.amazon_store column (which was completely empty and unused). This change should have no impact on mirror servers, unless you were using this table or column for your own purposes, because they should be otherwise empty.
  • MBS-12141: Block tag names that are empty or have uncontrolled whitespace with database constraints. Recently we discovered a bug where empty or blank tag names could be submitted in the web service. This has since been fixed, but we’d also like to prevent such empty tags by adding a database constraint. This change has no effect on mirror servers schema-wise, where such constraints are not created. A few blank tags have already been deleted from the production database, but otherwise existing data is not affected. If any such tags exist in your standalone database, they’ll be deleted.
  • MBS-12252: Add edit_genre table. A requirement to start storing edit history for genres (right now changes leave no trail). This will add the empty table to mirror servers as well, but will not affect any existing data.
  • MBS-12253: Add relationship tables for genres. A requirement to be able to relate genres to other entities (such as URLs for the equivalent Wikipedia or Rate Your Music pages). This will add the empty tables (and accompanying example tables in the documentation namespace) to mirror servers as well, but will not affect any existing data.
  • MBS-12254: Add genre_annotation table. A requirement to make it possible to eventually add annotations to genres. This will add the empty table to mirror servers as well, but will not affect any existing data.
  • MBS-12255: Add genre_alias_type table and make genre_alias consistent. Originally the (as yet unused) genre_alias table was designed as a heavily simplified version of the alias tables for other entities. In retrospect, this was not a good decision, since it would make it harder to just use the generic implementation of our alias code for genres. As such, we’re adding a genre_alias_type table (originally genre aliases had no types) and replacing the genre_alias table with one having the extra columns matching other entities’ alias tables. These changes will also happen to mirror servers, but since the genre_alias table was completely unused it should not cause any issues. In case any standalone (not mirrored) servers were using genre_alias, we will ensure any existing data is transferred to the new version of it.
  • MBS-12241: Drop the whitespace_collapsed database constraint. We’ve had a constraint for years that tries to ensure that columns like entity names do not contain multiple consecutive spacing characters (disallowing names such as “This    Title”). In retrospect, this was overreaching, since there are several cases in which a specific number of spaces in a title can be shown to be artist intent. Additionally, we recently discovered that we had some very old data in the database that actually violated this constraint (causing issues when importing data to a standalone server). The data seemed to actually be correct (i.e. some of the aforementioned edge cases) so rather than amending it, we’re removing the constraint. This will have no effect on mirrors since they don’t run constraints.
  • MBS-12225: Rename “slave” to “mirror” (inclusive language update). We recently got a request from a long-time supporting organization to pick a different term for what we’ve historically called “slave server”. Since we were already sometimes using “mirror server” to mean the exact same thing, we are just changing the official name and will use “mirror server” in the future. RT_SLAVE will still work in, at least for now, but we’d suggest changing to the new (and equivalent) RT_MIRROR in your mirror servers’ We’re likely to eventually drop support for RT_SLAVE in a future schema change, so we’ll remind you about changing it in future upgrade instructions.
  • MBS-12190: Add Mood support. Music mood was originally meant to be automatically calculated by the now-discontinued AcousticBrainz project. That’s obviously no longer in the cards, but this data would still be quite useful for ListenBrainz. As such, we’re planning to add basic support for mood tags in MusicBrainz in the same way we currently do genres. This can then be leveraged by ListenBrainz to collect the information directly from users playing music through their BrainzPlayer, and it can also of course be entered directly from MusicBrainz in the same way other tags (including genre tags) can. This will add new mood tables to mirrors and will detect some previously generic tags as mood tags, but it won’t cause any changes to the underlying data.
  • MBS-11760: Expand the database triggers which remove empty tags to all entities. When the last use of a tag (up- or downvote) is removed, we use triggers to completely remove the tag from the database. Some of the relevant triggers (for events, places, recordings and releases) were never created though, so if the last use was on an entity of one of those types the empty tag would not get purged. This doesn’t affect mirrors directly since the triggers don’t run on mirrors (but they should no longer get unused tags coming through replication).
  • MBS-11457: Drop series ordering_attribute. This column was added back when we were expecting to have different types of ordering attributes for series, but we have never used it. We planned to remove it last year already, but that required equivalent changes on the search server that couldn’t be made at the time. We are planning to just drop the column.
  • MBS-11456: Add MBIDs and redirect tables for artist credits. Adds a gid column to the artist_credit table, and a new artist_credit_gid_redirect table. It generates MBIDs for existing artist credits that will be replicated to mirrors.

    Artist credit MBIDs will be mainly exposed through the web service at first. The MBIDs will allow public identification of artist credits outside of MusicBrainz, and open the possibility of some more features in the future.
  • MBS-12208: Show withdrawn release groups in the official artist overview. The Withdrawn release status was added recently. Release groups containing only releases with this status were meant to be shown in the main (official) artist overview, but the way this is implemented means a small edit to the get_artist_release_group_rows function was needed. Mirrors using the materialized tables will need to update the data; more info will be provided as part of the upgrade instructions.

We’ll post upgrade instructions for standalone/mirror servers on the day of the release. If you have any questions, feel free to comment below, or on the linked JIRA tickets if relevant there!

NB: This post was updated on 21 March to include a ticket (MBS-12208) that we forgot to list originally

Planned downtime for Wednesday, March 2, 16:00 UTC

We’ll be performing some critical maintenance on our database server starting at 16:00 UTC on March 2. Some brief downtime (hopefully less than 15 minutes) will be required to transfer services from our primary database server to our standby, which will allow us to upgrade the primary’s system and perform hardware checks. Thanks for your patience during this time.

MusicBrainz Server update, 2021-09-06

Today we’re happy to release yyoung’s work to improve the external links editor; see his detailed blog post for more information. Thanks for your hard work, yyoung!

This release also contains quite a few bug fixes and improvements, given the amount of time since last release. Several fix guess-case issues, and we’ve refactored the guess-case code to be more maintainable in the future. A visible improvement you may notice is that we now display icons next to entity links in relationships to help distinguish different types of entities. (If you’ve been editing on MusicBrainz for a long time, you may remember something similar from the classic, pre-NGS website.)

A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.

Thanks to aerozol, angriestchair, Beckfield, bsammon, chaban, CyberSkull, danBLOO, Dibou, Freso, HDS, jesus2099, KRSCuan, mr_maxis, mtrolley, navap, salo.rock, Shepard, yindesu, and yyoung for having reported bugs and suggested improvements. Thanks to Besnik, ffff23, kellnerd, mfmeulenbelt, panos, salo.rock, th1rtyf0ur, V6lur, and yoshi818 for updating the translations. And thanks to all others who tested the beta version!

The git tag is v-2021-09-06.

Fixed Bug

  • [MBS-11793] – Wikipedia abstract is fetched even though URL is ended
  • [MBS-11795] – Text overflow in external link relationship type description tooltip
  • [MBS-11802] – ISE on “Edit relationship type” edit for removed type
  • [MBS-11806] – Relationships for different tracks are wrongly grouped on release bottom credit display
  • [MBS-11812] – Merge queue: Missing whitespace before “New disc title”
  • [MBS-11832] – artist-credit/id page gives TypeError if the id does not exist
  • [MBS-11854] – Guess Case doesn’t properly capitalize after Unicode hyphen U+2010
  • [MBS-11861] – Weird odd/even classes client-side for tablesorted statistics
  • [MBS-11864] – Some DNB links are wrongly marked as invalid
  • [MBS-11922] – pre-NGS release type not shown for compilation
  • [MBS-11933] – /oauth2/token doesn’t validate the code parameter


  • [MBS-2221] – Description for how to set a relationship as “in” a date
  • [MBS-2418] – Show “Edit URL” edits in entity edit histories
  • [MBS-2421] – Small icon near recording / work / release / artist / … names to distinguish them
  • [MBS-3774] – Add URL relationship with begin and end dates
  • [MBS-7859] – Hide relationships from original recordings to other/derived versions in release view
  • [MBS-10054] – Better editing/viewing of URL relationships from Artist page
  • [MBS-10910] – Display renamed labels on Overview
  • [MBS-11267] – Show label for cover art pieces when reordering cover art
  • [MBS-11391] – Show changes made to external link when editing URL relationship
  • [MBS-11622] – Clean up Apple Music label URLs
  • [MBS-11650] – Add Tag statistics to profile page
  • [MBS-11680] – Group editing URL relationships by external link
  • [MBS-11693] – Give useful message when rejecting Musixmatch /album links
  • [MBS-11722] – Don’t preselect basic as language proficiency
  • [MBS-11732] – Remove LYRICSnMUSIC from lyrics whitelist
  • [MBS-11733] – Remove WikiaParoles from lyrics whitelist
  • [MBS-11788] – Guess case: Lowercase “official” in ETI
  • [MBS-11796] – Add Internet Archive logo for sidebar
  • [MBS-11797] – Guess case: Lowercase “censored”, “uncensored”, “explicit” in ETI
  • [MBS-11798] – Disallow Instagram /accounts link and other internal links
  • [MBS-11808] – Don’t show entities in tag pages where vote count for tag is lower than 1
  • [MBS-11810] – Merge queue: Rename “disc title” to “medium title”
  • [MBS-11811] – Make Tracklist editing buttons behave consistently on collapsed mediums
  • [MBS-11823] – Don’t insert line breaks inside tag words
  • [MBS-11824] – featured artist reports should look for featured artists without a space
  • [MBS-11825] – Use consistent order for art types when editing vs adding cover art
  • [MBS-11833] – Drop “f.” from the featured artists reports
  • [MBS-11846] – Display release artist on release group view
  • [MBS-11850] – Make footer links more visible
  • [MBS-11862] – Do not show deprecated relationship types with 0 uses in selectors
  • [MBS-11863] – Allow DNB links for works
  • [MBS-11875] – Braille should not be looked for in “Releases with unlikely language/script pairs” in connection to a spoken/written language
  • [MBS-11888] – Automatically set/disable ended when setting an end date in DateRangeFieldset
  • [MBS-11891] – Use HTTPS when linking to Jira
  • [MBS-11912] – Also allow Mainly Norfolk as a lyrics source
  • [MBS-11913] – Auto-select “stream” additionaly to “download” for Jamendo URLs
  • [MBS-11915] – Don’t show area icon if there’s already a flag icon
  • [MBS-11924] – Remove redundant tabs/links/info from deleted editor profiles

New Feature

  • [MBS-9426] – Interface to remove usernames from blocked list
  • [MBS-9902] – Support auto-select/cleanup/validation of more than one relationship type for external links
  • [MBS-11689] – Report: pseudo-releases marked as the original tracklist
  • [MBS-11828] – Add admin interface for checking whether a username is blocked
  • [MBS-11848] – Add report for “Releases with Amazon cover art without any Cover Art Archive images”

React Conversion Task

  • [MBS-11834] – Convert Add Release edit to React
  • [MBS-11835] – Convert Change Wikidoc edit to React
  • [MBS-11836] – Convert Edit Barcodes edit to React
  • [MBS-11837] – Convert Edit Release Label edit to React
  • [MBS-11838] – Convert Edit Release edit to React
  • [MBS-11839] – Convert Remove Relationship Attribute edit to React
  • [MBS-11840] – Convert Reorder Mediums edit to React

Other Task

  • [MBS-11805] – Add flow typing to guess case code
  • [MBS-11856] – Remove reports for releases with cover art relationships
  • [MBS-11928] – Drop consul-template for deployment

PostgreSQL 12 Upgrade Instructions for MusicBrainz Server

Thanks to everyone for your patience during our downtime today. As promised, here are steps to follow to upgrade your own PG instance to v12. (Confused? See the previous blog post on this subject.)

If you’re already running v12, there are still some instructions you must follow!

For MusicBrainz Docker

If you’re running the new MusicBrainz Docker setup, an upgrade script exists for you to use. See the release notes for specific – hopefully brief – instructions.

For a Manual Setup ( Based)

If you aren’t using Docker but rather set up musicbrainz-server by hand following, see the steps below.

Know that as an alternative, you can always import new data dumps from scratch (again following the steps in into a new PG 12 cluster. Just make sure you’re on the v-2020-05-18-postgres12 tag of musicbrainz-server while doing so.

If on the other hand you don’t mind getting your hands a bit dirty, you can use the quicker method below. Like, this assumes you’re using Ubuntu/Debian and their postgresql-common cluster management tools.

If you’re already running v12, you should still follow these steps; however, you can skip the ones involving apt-get, pg_dropcluster, and pg_upgradecluster. The main steps you need to follow in this case are running the 20200518-pg12-before-upgrade.sql and 20200518-pg12-after-upgrade.sql scripts in that order.

On distros other than Debian/Ubuntu where the postgresql-common tools aren’t available, you’ll have to manage with initdb and pg_upgrade on your own.

  1. First take down the web server running MusicBrainz (stop plackup) to prevent database access.
  2. Turn off any cron jobs updating or accessing the database (e.g. for the live data feed/replication packets).
  3. Switch to the latest musicbrainz-server code with:
    git fetch origin && \
    git checkout v-2020-05-18-postgres12
  4. With PG 9.5 (or whatever version you’re using) still running, run the following “pre-upgrade” script:
    psql -U postgres -d musicbrainz_db \
    -f admin/sql/updates/20200518-pg12-before-upgrade.sql

    This assumes that “postgres” is the name of your PG superuser, and “musicbrainz_db” is the name of your database. If you see a few messages about things not existing, that’s normal.

  5. Install packages for PostgreSQL 12. On Ubuntu/Debian you can obtain them from the PGDG apt repo.
    apt-get update && \
    apt-get install postgresql-12 postgresql-server-dev-12

    If you’re installing postgresql-12 for the first time, this will automatically create a new cluster at /var/lib/postgresql/12/main. Remove that empty cluster. Don’t run this if you already had v12 installed and have data there!

    pg_dropcluster --stop 12 main
    If you did already have v12 installed with musicbrainz_db running there, leave the cluster alone and skip the next step involving pg_upgradecluster.

    In the unlikely event that you already have a v12 cluster, but also have musicbrainz_db running in a separate, older cluster, these instructions won’t work for you. We recommend importing fresh data dumps into the v12 cluster and dropping the old one.

  6. Upgrade the old cluster. This assumes it’s version 9.5; if you’re using version 10 or 11, make sure to replace 9.5 below with 10 or 11. If you have other databases in your old cluster besides musicbrainz_db, be aware that this will upgrade all of them to PG 12.
     pg_upgradecluster -v 12 9.5 main
  7. If all goes well, the new cluster should be up and running. (You can drop the old one if you like; the output of the pg_upgradecluster command will tell you how.) Now run the following “post-upgrade” script on the database:
    psql -U postgres -d musicbrainz_db -f \
    This may take a bit, as it has to recreate some indexes.
  8. The upgrade is complete. You can turn cron jobs back on, if applicable.
  9. Restart the MusicBrainz web server / plackup, if applicable. If you’re accessing the server in a web browser, the usual release upgrade steps apply, like running ./script/ again.

If you run into any trouble following the above, please let us know and we’ll try to help resolve your issue as soon as possible!

Reminder: Upgrading to PostgreSQL 12 on May 18, 2020

As we announced in February, in two weeks time (May 18, 2020) we’ll be upgrading our production database server to PostgreSQL v12 (from v9.5). At the same time, v12 will become the minimum supported version for MusicBrainz Server, so we ask that you upgrade afterwards as soon as possible! If you’re still unsure, a Q&A is below.

When do I need to upgrade my postgres by?

As soon as possible after May 18 if you’d like to keep your musicbrainz-server code up to date.

How do I perform the upgrade?

We’ll provide instructions closer to May 18. It’s recommended that you don’t upgrade until then, since we’ll be providing scripts to resolve some issues.

Will the live data feed (replication packets) stop working right away if I don’t upgrade?

No, as long as you keep your musicbrainz-server code checkout on the v-2020-05-11 tag (which will be the final release before May 18) or earlier. Future releases may work for a while too.

This is not a schema change release, so replication will continue to work smoothly until you upgrade. No tables or views will change.

However, to make the upgrade process smoother we’ll be dropping the musicbrainz-collate and musicbrainz-unaccent extensions, instead using PG’s builtin collation support for the former and replacing the latter with the unaccent extension from postgresql-contrib. A few SQL functions are being added to enable this, and some indexes need to be rebuilt. This will all happen as part of upgrade scripts we provide (or you can import from scratch). Some features of musicbrainz-server that use these old extensions may cease to work if you don’t apply them.

The extension changes above don’t actually make use of any new PG 12 features. We’ll avoid using such features for at least 1 month.

If I’m already running PostgreSQL 12, do I need to do anything?

Yes, but things will be easier for you. As mentioned in the previous answer, we’ll be dropping the musicbrainz-collate and musicbrainz-unaccent extensions to make the upgrade process smoother for pre-v12 instances. So you’ll only have to run some upgrade scripts we provide to replace those extensions and rebuild some indexes.

My host/distribution doesn’t have PostgreSQL 12 yet!

If you’re running Debian or Ubuntu, the PGDG maintains an APT repository with the latest versions. These are the same packages MetaBrainz uses in production.

Amazon RDS supports PostgreSQL 12 since March 31.

I absolutely cannot upgrade yet! What should I do?

You can stay on the v-2020-05-11 release of musicbrainz-server or earlier until then. Replication packets (i.e. the live data feed) will continue to work until the next schema change on that tag, but you’ll have upgraded to v12 by then, right?

Instead of performing a pg_upgrade and running these upgrade scripts you mentioned, can I just import fresh data dumps into a new v12 cluster?

Of course. Just make sure your musicbrainz-server git checkout is on the v-2020-05-18 tag (once that’s released) or later before performing the import. And keep in mind it may be slower than a direct upgrade.