Database updates, upgrades and end of life

Every managed database page has a Version card: the version it actually runs (e.g. PostgreSQL 16.4), the image tag it was created with (16-alpine), and a status badge. The databases list shows the same badge.

MarvX checks each database once a day. Check now on the Version card checks immediately. Owners and admins get one bell notification and email per new update, per new major version and per end-of-life warning.

Nothing changes until you choose. You can always leave a database on the version it runs.

Security & bug-fix updates (same version)

Click Update now (developers and up). What happens:

1. Backup of your data first. It appears under Backups. If the backup fails, the update is cancelled and nothing changes. (Redis and libSQL can't be dumped, so their data volume is simply kept.)
2. Download the new build.
3. Restart the database on the new build with the same data, name, host, port, user and password. Expect under a minute of downtime. Apps don't need changes.
4. Health check: the database must answer and report the expected version.
5. If the restart or health check fails, MarvX rolls back automatically to the exact previous version on the same data and tells you.

Progress shows step by step on the Version card. Only one update or upgrade runs at a time per database.

Skip this update hides it until a newer build comes out. You can still install a skipped update.

Auto-install security updates (off by default) installs these updates for you between 02:00 and 05:00 UTC with the same backup and rollback. A build that failed or rolled back once isn't retried automatically. Major versions are never installed automatically.

Updates need object storage for the safety backup. If the server has none, Update now explains this and does nothing.

Why minor updates are safe in place

• PostgreSQL minor releases (16.x) never change the data format.
• MySQL and MariaDB patch releases inside a series (8.0.x, 10.11.x) are drop-in.
• MongoDB patch releases (7.0.x) are drop-in.
• Redis reads its own files across releases of the same major.

If an image tag moves to a new series (for example mysql:8 now ships 8.4, or mariadb:11 moves from 11.4 to 11.8), it's not applied in place. The card offers it as a guided upgrade instead.

Major upgrades (new version)

Majors (PostgreSQL 16 → 17, MongoDB 7 → 8, MySQL 8.0 → 8.4, MariaDB 10.11 → 11, Redis 7 → 8) are never done in place. Click Upgrade to 17. The wizard:

1. Backs up the current database.
2. Creates a new database next to it, named after it with a version suffix (orders-v17), with the same user, password and database name.
3. Copies your data with a logical dump and restore.
4. Verifies the copy (tables, or MongoDB collections and documents, match).
5. Leaves both running side by side. Your apps still use the old one.

Then switch your apps:

• Switch my apps replaces the old database's private host (marvex-db-<old id>) with the new one in every app's environment variables that reference it, and redeploys those apps. Only the host changes.
• Or edit DATABASE_URL yourself and redeploy.

Writes made to the old database after the backup aren't copied. Pause writes or pick a quiet moment. Check your app's database driver supports the new version.

The old database is kept for 7 days. Then owners get a reminder, and it's deleted 3 days later unless you click Keep … — don't remove it. It's never deleted while any app still references it. In that case it's kept and you're reminded again a week later. When deleted, its backups move to the upgraded database. You can also delete the old database yourself at any time.

If an upgrade fails, the half-made new database is removed. Your current database isn't changed.

MongoDB: one major at a time

MongoDB only starts on data whose featureCompatibilityVersion is the previous major. Upgrades must go 6 → 7 → 8. Skipping (6 → 8) is refused with an explanation. Upgrade to the next major first, switch, then upgrade again.

Redis and libSQL

They can't be copied with a logical backup, so major upgrades aren't automated. Create a new Redis database on the newer version and point your apps at it. (Redis is usually a cache that refills itself.)

End of life

Each engine version has an end-of-life date: the day it stops getting security fixes. Examples (set by MarvX admins, from the vendors' published policies):

The Version card shows an amber warning from 6 months before the date and a red one after. The fix is a major upgrade.

Who can do what

• Everyone in the workspace can see versions, updates and progress.
• Developers, admins and owners can update, skip, upgrade, switch apps, keep the old database and change auto-install.
• Viewers are read-only.

Troubleshooting

• "updates take a safety backup first…": object storage isn't configured on this server. Contact support.
• Update rolled back: the new build didn't pass the health check. Your database runs the previous version with the same data. The next newer build is offered when it comes out. Contact support if it repeats.
• "MongoDB upgrades go one major version at a time": upgrade to the next major first.
• "an update or upgrade is already in progress": wait for the current one. Progress is on the Version card.
• Apps still slow or failing after switching: check the app redeployed, and its driver supports the new version.