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 and MariaDB to MySQL (either direction). MariaDB to MySQL needs the Solo plan or above, because that is where MySQL starts; the Convert tab tells you so instead of failing halfway. It is also the one direction where your source engine can have features the target cannot take, so read the pre-check.
• 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.

Your plan has to include the engine you are converting to. That only ever bites on MariaDB to MySQL, the one conversion that moves up a plan: MariaDB is on the Free plan and MySQL starts on Solo, so the Convert tab only appears on a MariaDB database once you are on Solo or above. Every other conversion is available on every plan.

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 either MySQL-family direction 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.

Converting a MariaDB database to MySQL has four caveats of its own. The first two are features MySQL simply does not have, and each stops the copy on the table that uses it, so fix those on the MariaDB database first. The third the copy handles for you. The fourth changes nothing about your data but does change how a client on the direct port authenticates, so read it before you cut over.

• MariaDB-only column types: UUID, INET4, INET6, and VECTOR. Change them to something MySQL knows (binary or character columns) and adjust your application to read the new representation.
• Sequences. MySQL has no sequence objects at all, so anything calling NEXTVAL stops working. Replace them with an AUTO_INCREMENT column or a counter table.
• MariaDB collations, which the copy maps for you. MariaDB 11.8 and newer make utf8mb4_uca1400_ai_ci the default database collation, so nearly every table declares one and MySQL has no matching name. The conversion rewrites them to MySQL's utf8mb4_0900 family as it copies: _ai_ci becomes utf8mb4_0900_ai_ci, _as_cs becomes utf8mb4_0900_as_cs, and anything else lands on the closest 0900 form. You do not have to change a table's collation first. The one real consequence is that the two UCA versions sort a little differently, so spot-check queries whose results depend on sort order or on where a range boundary falls.
• The authentication change, which is a note rather than something to fix. MySQL authenticates with caching_sha2_password where MariaDB uses its own plugin. Clients on the pooled connection are unaffected; a client on the direct port needs a driver that speaks it and has to reconnect after the cutover, including on the original address if you keep it.

The pre-check reads these from your schema, so when it can reach your database it tells you how many of each you actually have rather than listing hazards in the abstract. It is best-effort, though, not a guarantee: it does not wake a parked database just to inspect it, the probe can fail on its own, and it only looks for the features on that list. A copy can still stop on something the pre-check never saw. The backstop is the row-count comparison after the copy, described above: read it before you archive the original.

A MariaDB source is dumped with MariaDB's own dump tool and the dump is then normalized for MySQL before it is loaded, which is where the collation rewrite happens along with stripping the sandbox header MariaDB writes and a sql_mode flag MySQL does not accept.

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 conversion between MySQL and MariaDB, in either direction, 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 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-family 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.