Guide

Converting an engine

Some engines have a close sibling that can take over the same schema and data, so you can switch a database from one to the other without rewriting your queries. 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 close enough that your schema and rows carry across without a rewrite. Most pairs also share a wire protocol, so your drivers, ORMs, and queries keep working unchanged, and the copy is value-for-value complete. The SQLite to libSQL pair is the exception on both counts: the SQL is the same, but the client library changes, and a few things are rebuilt rather than copied (full-text search index content, which you rebuild after converting, and generated columns, which the new database recomputes from your table definitions). The pre-check names anything in that category for your database before the copy starts. 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)
• SQLite to libSQL (one direction). Not a drop-in swap: Layerbase serves SQLite over the Postgres wire, so you connect with psql or a Postgres driver, while libSQL answers on an HTTPS endpoint and needs the libSQL client (@libsql/client) with an auth token. Expect a code change at cutover. There is no libSQL to SQLite 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 engines, including SQLite to libSQL) or key counts (Redis and 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.

Some parts of a copy can finish incompletely without the copy itself failing: a view that will not recreate on the new engine, a full-text index whose content you have to rebuild, a table whose row counts do not line up. Those are listed on the Convert tab when the copy finishes, above the button that archives the original, and again in the archive confirmation. If you see them, deal with them before you archive: the archived original stops accepting connections.

A quick compatibility pre-check runs first. If your database uses features the copy will not carry across verbatim, you see those caveats before anything is created: for MySQL that means stored routines, events, or custom definers, and for SQLite to libSQL it means the client-library change plus things like full-text search indexes that need rebuilding, generated columns, triggers, and views. Anything that needs a decision from you asks you to acknowledge it before the conversion starts.

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.

The pre-check itself is read-only and best-effort, so it does not always run: a parked source is not started just to inspect it, and the probe can fail on its own. When that happens the screen says so instead of staying silent, and it still shows the caveats that follow from the engine pair alone, such as the SQLite to libSQL client-library change. The copy is unaffected: it reports hard failures loudly and never modifies the source.

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.

Keeping the address is a MySQL to MariaDB feature only. Redis and Valkey conversions do not support it yet, and SQLite to libSQL cannot support it at all: the two engines answer on different kinds of endpoint, so there is no shared address to move. For those pairs, switch your app to the new database's connection details first, then archive the original. For SQLite to libSQL that also means swapping in the libSQL client and its auth token, not just a new host.

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.