Guide

Converting an engine

Some engines speak the same wire protocol as a close sibling, so you can switch a database from one to the other without rewriting a line of application code. The Convert tab on a database's page does this for you: it copies your schema and data into a new database on the other engine and leaves the original untouched until you say otherwise.

Which conversions are supported

Conversion is only offered between engines that share a wire protocol, so your drivers, ORMs, and queries keep working unchanged. The supported directions today are:

• MySQL to MariaDB (one direction: a MySQL database can convert to MariaDB)
• Redis to Valkey and Valkey to Redis (either direction)

The Convert tab only appears on a database whose engine has a supported target. If you do not see it, that engine has no conversion path.

It is non-destructive

Converting creates a brand new database next to the original on the same server. Your source database is read once and never modified. The schema and data are copied into the new database, and both exist side by side until you decide to finish. If you do nothing, both databases stay exactly as they are.

While both databases exist, the temporary second one does not count against your plan's database limit. That means you can convert even when you are already at your limit: the extra slot is allowed for the duration of the conversion and is freed when you archive the original.

How it runs

Click Convert and Layerbase brings up the new database (this takes about a minute), then copies your schema and data into it automatically. When the copy finishes, Layerbase verifies it by comparing row counts (SQL) or key counts (Redis/Valkey) and shows the result. You can close the tab during the copy; it keeps running server-side, and the page re-attaches to it when you return.

For MySQL, a quick compatibility pre-check runs first. If your database uses features a plain dump will not carry across, such as stored routines, events, or custom definers, you see those caveats before anything is created.

Conversion works even if the source is stopped, locked, or archived. Layerbase brings it to a readable state for the copy. The one exception is a database that was removed after long inactivity (offloaded): restore it from its final backup first, then convert.

Finishing the cutover

Once the copy is verified, spot-check the new database in the query console, then finish the conversion. Finishing takes a fresh final backup of the original and archives it, which frees the temporary second slot. Archiving is reversible: the data is kept, nothing is deleted automatically, and an owner whose plan includes the source engine can restore it later.

Keeping your connection address

For a MySQL to MariaDB conversion, you can keep your existing connection string. When you finish, the Keep this database's address toggle (on by default) moves the original host, port, and password onto the new MariaDB database. Your application keeps working with the connection string it already has: nothing to redeploy. Expect roughly a minute of downtime during the handover.

If you would rather cut over deliberately, turn the toggle off. Then you copy the new database's connection string into your app and deploy before archiving the original.

Redis and Valkey conversions do not support keeping the address yet. For those, switch your app to the new database's connection string, then archive the original.

The grandfathering banner

If a plan change moves one of your engines above your current tier, existing databases on that engine are grandfathered: they keep running until a stamped deadline instead of stopping immediately. An amber banner across the dashboard shows the earliest deadline.

For MySQL, the banner offers converting to MariaDB to stay on the free path, or upgrading to keep MySQL. Once a converted copy is ready, the banner switches to guiding you through the finish: switch your app over, then archive the original from its Convert tab. If the deadline passes without either, the database is locked rather than deleted, and the locked-database recovery paths apply.