Hi — I’m building a self-hosted tool that reads BookBrainz author data. I moved it off the web service and onto the database dumps specifically to stop putting load on your API, and I wanted to ask what the plan is for them, because the directory they lived in is now empty.
What I’m seeing. The Develop page ( Develop – BookBrainz ) documents a weekly database dump and points at Index of /pub/musicbrainz/bookbrainz/ . As of 2026-08-03 that directory lists no files at all, and latest.sql.bz2 returns 404. It’s the same on data.metabrainz.org, so it isn’t one mirror lagging.
Before that, what the directory showed was:
MD5SUMS 11-May-2026 01:11 187
SHA256SUMS 11-May-2026 01:11 283
bookbrainz-dump-2026-05-04.sql.bz2 04-May-2026 01:10 120M
bookbrainz-dump-2026-05-11.sql.bz2 11-May-2026 01:10 120M
latest.sql.bz2 11-May-2026 01:10 120M
so the newest was 2026-05-11 and nothing new had appeared for about twelve weeks before everything was removed. I’ve no idea what’s behind either the pause or the removal, and I’m not assuming anything is wrong — it may well be deliberate.
One thing that might be worth a glance, though you’ll know instantly whether it’s relevant. That last dump is timestamped 2026-05-11 01:10 UTC, roughly fourteen hours before the maintenance window announced for 15:00 UTC that same day, which named BookBrainz among the affected services and described upgrading the production database to PostgreSQL v18:
I only connect the two because of a note in your own history: PR #1187 (“Update and fix DB dumps scripts”) lists “mismatch of pg_dump version causing the script to fail” as the first of the issues it fixed, and carried a PG_MAJOR bump to 16 for that earlier upgrade — Update and fix DB dumps scripts by MonkeyDo · Pull Request #1187 · metabrainz/bookbrainz-site · GitHub . So a version bump being needed after a server upgrade seems to be a thing that has come up before here. I have no visibility into how the dumps are actually produced and may well be pointing at nothing — treat it as a “have you already ruled this out?” rather than a diagnosis.
What I’d like to know. Simply whether the dumps are expected to return, are moving somewhere else, or are being retired. I’m not asking anyone to hurry — I just don’t want to build on a distribution channel that isn’t coming back, and if the answer is “use the web service,” I’d rather know now and design for it.
Why I care rather than just moving on. Of everything I’ve evaluated for author identity, your data is the best structured by a wide margin. Four things in particular I can’t get elsewhere without hand-curation: aliases tagged by language with a primary marked per language, rather than one flattened name string; sort names given explicitly instead of guessed from a comma heuristic; pen names modelled as their own entities rather than collapsed into the author they belong to, which is exactly the distinction that’s hardest to reconstruct downstream once it’s lost; and typed authority identifiers — VIAF, ISNI and ORCID alongside the cross-walk out to Wikidata, Goodreads, OpenLibrary, LibraryThing and MusicBrainz — on the same record. In my last pass that was 44,981 alias spellings across 31,197 authors, and 48,593 authority identifiers spread over the 17,761 authors that carry at least one — averaging close to three apiece on an identified author, which no other free source I’ve looked at comes near.
Coverage is naturally narrower than the big commercial catalogues, and that’s fine — I use other sources for reach. But where BookBrainz has a record, it’s the one I trust, and it’s the only one that gets author identity right rather than treating a name as a string. That’s why I’d rather wait for a dump than route around you.
Thanks for all the work on BookBrainz.