# DBRepair repairs and compacts the Plex Media Server database from a terminal > DBRepair is a shell utility that checks, repairs, vacuums and reindexes the Plex Media Server SQLite databases, with commands for importing watch history and replacing a broken database from a Plex backup. The script requires Plex Media Server 1.43.0 or newer, and the last push was on 2026-10-18. **ChuckPa/DBRepair** — Database repair utility for Plex Media Server databases - Repository: https://github.com/ChuckPa/DBRepair - Stars: 1,771 · Forks: 68 - Language: Shell - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/chuckpa-dbrepair ## The symptoms it targets are the ones Plex does not fix itself DBRepair is a database repair utility for Plex Media Server, and it opens by naming the situations it exists for. The list is a symptom list, not a feature list: searching that is sluggish or completely broken, a database that is reported as malformed, damaged or corrupted, a database that has bloated from media additions or changes, damaged indexes, importing data from other databases such as watch history, and cleaning up operational temp files that Plex has forgotten. Every one of those is a data-layer problem that the media server itself does not address. Plex manages a library of media, and the database underneath it accumulates rows and files as you add and change things. A user who notices that searching has become slow has no official repair path, which is the gap this utility occupies. It is a command line tool. The README states it is run from a terminal or an ssh or putty session with sufficient privilege to read and write the databases as a minimum, and that if root privileges exist and the environment supports it, the options to start and stop PMS are presented as well. Some environments require it to run as the root user. The repository is small and shell based. The top level holds DBRepair.sh, a License.md, a ReleaseNotes file, a Contributing.md, a Windows/ directory and a .github/ directory. The primary language is listed as Shell, and the menu banner shows a version string of v1.09.00. ## Sixteen commands, each accepted as a name, an abbreviation or a number The utility accepts command names, and the README is specific about how forgiving the parser is. Command names may be upper or lower case and may be abbreviated, with a four character minimum. The accepted set is given in one block: ``` AUTO(matic) - Automatically check, repair/optimize, reindex, and FTS rebuild in one step. CHEC(k) - Check the main and blob databases integrity (includes FTS index check) DEFL(ate) - Deflate a bloated PMS database (faulty statistics data) EXIT - Exit the utility IGNOre/HONOr - Ignore/Honor constraint errors when IMPORTing additional data into DB. IMPO(rt) - Import viewstate / watch history from another database PRUN(e) - Prune (remove) old image files from transcoder cache diretory PURG(e) - Purge (delete) all temporary files left behind by PMS & the transcoder from the temp directory REIN(dex) - Rebuild the database indexes (includes FTS indexes) REPL(ace) - Replace the existing databases with a PMS-generated backup SHOW - Show the log file STAR(t) - Start PMS (not available on all platforms) STOP - Stop PMS (not available on all platforms) UNDO - UNDO the last operation VACU(um) - Vacuum the databases ``` The parenthetical notation is the abbreviation hint, so CHEC works for CHECK and VACU for VACUUM. Two commands are worth pulling out because they show the design. IGNOre and HONOr is a toggle for whether constraint errors are ignored when importing data, which means the import path can either enforce referential integrity or push data in regardless. UNDO undoes the last operation, so the destructive commands have a way back. The menu reflects the same set, and the README notes that you can enter either the command number or the command name. The banner it shows lists stop, automatic, check, vacuum, repair, reindex, start, import and replace, and the import entry is explicitly labelled risky in the menu text itself, which is the author flagging the one command that writes foreign data into your database. ## Plex 1.43 changed the schema and the script had to change with it The most important thing in the README is a compatibility notice, and it is not a minor one. Due to changes in Plex Media Server beginning with PMS 1.43.0, the README says DBRepair.sh as currently written is being phased out in favour of a compiled C version of the program. The script in the main repository has been patched to disable FTS repair, which the author calls the safest option because as of PMS 1.43.4 the server handles FTS entirely itself. Existing 1.17.x packages have been taken down for everyone's safety, and the README says the script may safely be used for normal optimization but does not address any FTS issues. The reasons are structural rather than cosmetic. Changes in the SQLite version Plex uses required major changes to address incompatibilities seen between 1.42.2 and 1.43.x, and schema changes in PMS require DBRepair to perform its tasks differently. The listed symptom of the incompatibility is that the script falsely reports a malformed inverted index and marks the database as damaged, which is exactly the kind of false alarm that destroys trust in a repair tool. The forward plan is spelled out too. All versions of PMS below 1.43.0, including 1.42.2 from August 2025, will no longer be supported due to SQL incompatibilities, with the reason given plainly: the author cannot support two different database schemas. The script is to be updated to enforce the 1.43+ requirement, to use the new PMS SQLite version, and to use the new FTS, triggers and indexes commands and their sequencing. For Linux users who want to patch the script themselves, instructions were to be posted in the forum. ## The script is being replaced by a compiled program The direction of the project is worth understanding before you install anything. The README reports that the program version is stable and works for all but a few edge cases, and that those edge cases are how the program determines its host and identity. The compiled packages are distributed as ZIP files through a Plex forum development thread rather than through the GitHub repository, and the author says he expects to go live in production with regular releases again in late October or early November, with new commands and vastly improved performance. The status markers at the top of the README show the progression. A note dated 14-Oct-2026 says DBRepair is in release candidate pre-release final testing and is expected to launch on schedule, asking users to help give it a final spin. Earlier notes describe a beta testing phase and the special announcement that phased out the script. So there are two artefacts, and they are not interchangeable. The GitHub repository ships DBRepair.sh, the shell script, which is the version that now has FTS repair disabled and that requires Plex 1.43.0 or newer. The compiled program is a separate distribution channel, still in pre-release, and the script is described as being phased out in its favour. A reader who installs from GitHub today gets the older style of tool, in a reduced configuration, against a schema the author says the script was originally not written for. That is the state of the project as the README presents it. ## Upgrading a Plex install means dealing with the FTS gap There is a specific operational consequence in all of this, and it is the kind that is easy to miss. The commands list shows that CHECK, REINdex and AUTO all include FTS index work, and the announcement says the script's FTS repair has been disabled because PMS 1.43.4 now handles FTS entirely itself. If you are on a Plex version that does not handle it itself, the tool that used to fix your search no longer does, and the README's own symptom list still contains sluggish or broken searching as a reason to run the tool. The README also mentions that the author patched the main DBRepair.sh to disable FTS and removed the posted packages. Removing published packages is an unusual thing to do and it tells you how seriously the author treats a repair tool giving bad advice about a user's database. A repair utility that reports a healthy database as damaged, or a damaged database as healthy, is worse than no utility, because the user acts on what it says. The remaining functions are still meaningful. VACUum and DEFLate address a bloated database, which is the steady-state cost of adding and changing media, and those are the operations that do not depend on the FTS internals. UNDO is there as the safety net for the last operation. REPLace swaps in a PMS-generated backup, which is the recovery path when the database is genuinely beyond repair, and it is worth knowing it exists before you need it. ## Licence, support channels and the shape of the repository The repository carries a License.md file that GitHub does not classify as one of the standard open source licences, and the README does not summarise its terms. The project's licence status therefore has to be read from that file directly, and it is not something to assume if you intend to redistribute the script or fold it into your own maintenance tooling. Support runs through the Plex forums. The README links a development thread under a dbrepair-development heading, and the announcements point to specific posts in that thread for the current packages and for patch instructions. There is also a GitHub issues badge at the top, a Contributing.md file and a.github/ directory, so issues and pull requests are both expected channels. The README carries a Maintenance badge and a sponsor badge for the author, and the release badge points at the releases page, although the repository has no GitHub releases, which is consistent with the distribution model described above, where compiled packages are posted to the forum. The Windows/ directory at the top of the repository suggests a Windows path for the tool and the start and stop commands are marked as not available on all platforms, so the ability to stop the server before you touch the database depends on the environment. The ReleaseNotes file at the root is where the change history lives, since there are no tagged releases to read instead. ## Conclusion DBRepair fits a Plex administrator whose search is slow, whose database has bloated, or whose indexes are damaged, and who is comfortable running a root level shell script against a live database. It does not fit anyone running Plex Media Server below 1.43.0, since the README states the older versions are unsupported because of SQL incompatibilities, and it does not fit a user who wants a graphical tool. Verify first that your Plex version is 1.43.0 or newer and that the shell script is still the right artefact for your install, because the author is replacing the script with a compiled program and the FTS repair path in the script has been disabled. ## FAQ ### What does DBRepair do for Plex Media Server? It checks, repairs, optimizes, vacuums and reindexes the Plex Media Server databases, and it can import watch history from another database, prune the transcoder cache, purge leftover temp files and replace the databases with a PMS-generated backup. The README frames it as a response to sluggish search, bloated or damaged databases and damaged indexes. ### How do I run DBRepair and what commands does it accept? You run it from a terminal or ssh session with privilege to read and write the databases. Commands may be upper or lower case and abbreviated to four characters, and you can also enter the command number from the menu, for example AUTO for check, repair, reindex and FTS rebuild in one step. ### Does DBRepair still work with Plex Media Server 1.42 and older? No. The README states that all versions of PMS below 1.43.0, including 1.42.2, will no longer be supported due to SQL incompatibilities, and the script in the repository has been patched to disable FTS repair, with enforcement of the 1.43+ requirement listed as an upcoming change. ### What is the difference between DBRepair.sh and the DBRepair program? DBRepair.sh is the shell script in the repository, and because of changes in Plex Media Server 1.43.0 it is being phased out in favour of a compiled C version of the program. The compiled packages are distributed as ZIP files through the Plex forum development thread rather than through GitHub. ### Can I undo a DBRepair operation? Yes. UNDO is one of the accepted commands and undoes the last operation. The README also lists a replace command that swaps the existing databases with a PMS-generated backup. ## Sources - [ChuckPa/DBRepair on GitHub](https://github.com/ChuckPa/DBRepair) - [Issues](https://github.com/ChuckPa/DBRepair/issues) - [README](https://github.com/ChuckPa/DBRepair/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chuckpa-dbrepair