After reinstalling a database through my package manager, the service will not start and reports an input/output error

The bootstrap error is the service manager reporting that the process it launched exited immediately. It is not the real error, it is the wrapper telling you something failed underneath, which is why it is useless on its own.

Read the database's own log. The package manager writes logs to a known location, and the log will contain the actual reason. That single step turns this from guesswork into a specific fix, and it is the step people skip.

In the overwhelming majority of these cases the reason is a data directory left over from an older major version. Database servers of this kind store data in a version-specific on-disk format. Reinstalling gives you a newer major version, which starts, looks at the existing directory, finds a format it does not understand, and exits.

So the sequence is: install newer major version, old data directory present, immediate exit, unhelpful wrapper message.

Once you have confirmed that from the log, the fix depends on one question: do you care about the data?

If yes, there is a supported upgrade path. The database ships a tool for upgrading a data directory from one major version to the next, and the package manager usually provides a wrapper for it. This is the correct route and it preserves everything. Take a copy of the data directory first.

If no, and for a development machine this is often the honest answer: remove the old data directory and initialise a fresh one. Your databases are gone, which is fine if they were scratch, and the service starts immediately.

One thing worth checking before either: when the package manager upgrades a package like this, it often prints a message telling you exactly what to run. That message scrolls past and nobody reads it. It can usually be shown again with the package information command, and it frequently contains the whole answer.

The other family of causes for the same error, worth knowing if the log points elsewhere:

• A stale process still holding the port or a lock file. Check whether an old instance is running from a previous install.
• Permissions on the data directory, particularly after moving files or restoring from a backup.
• A leftover service definition pointing at paths that no longer exist. Removing the service registration and adding it again clears this.
• Full disk access or security restrictions on the directory, which on recent macOS releases can block a background service from reading a location you can read interactively.

That last one is a modern addition and it produces particularly confusing symptoms, because everything works when you run it by hand and fails when the service manager launches it.

A broader suggestion for development databases on a laptop: run them in containers rather than as system services.

Each project gets its own container with a pinned version and its own data volume. Upgrading one project does not affect another, versions never collide, and removing everything is one command. The whole class of problem in this thread disappears.

The package manager route is simpler for a single database you always want running, and it becomes fragile as soon as two projects want different versions.