Skip to content
Browse docs

Migrate an existing database into Layerbase

Bring a database over from another provider without a manual dump and restore. Layerbase reads your source once, copies the schema and data into a managed database, and never modifies the original. You can start from either a provider API key or a raw connection string.

Two ways to start

Seed a new database. Go to Create and choose Migrate to Layerbase (the /cloud/create/from-source flow). Layerbase provisions a fresh database on the matching engine and imports your source into it. This counts as a new database, so if you are at your plan limit you will be asked to free a slot or upgrade first.

Import into an existing database. Open a database you already created and use its Migrate tab. This overwrites whatever is in that database with the source data, so you confirm the overwrite with a checkbox before it runs. Use this when you created a blank database first (for example to pick a specific name, region, or plan settings).

Supported sources

The source list is grouped by the Layerbase engine you end up on. Migrating a database always keeps you on a compatible engine.

PostgreSQL

Neon, Supabase, Render, Railway, or any other Postgres by connection string.

MySQL / MariaDB

PlanetScale, or any MySQL or MariaDB by connection string. MariaDB is MySQL-compatible, so a MySQL source copies straight in.

Redis / Valkey

Upstash, Vercel KV, or any Redis or Valkey by connection string. Every key, type, and TTL is copied with a non-blocking scan.

Meilisearch

Algolia. Your index records, searchable attributes, ranking, faceting, and synonyms are translated into Meilisearch.

libSQL

Turso. Read over HTTP with your database URL and an auth token; every SQLite type is preserved.

API key or connection string

Some providers let you paste an account API key. Layerbase uses it once to list the databases in that account so you can pick the one to migrate, then copies it. Neon, Supabase, Render, Railway, PlanetScale, Upstash, Algolia, and Turso work this way. A few need a second value: Upstash needs your account email, PlanetScale needs the service token ID, and Algolia needs its Application ID.

Everything else takes a plain connection string. The key is used only to read your source and is never stored. For the least access, create a read-only or project-scoped key where the provider offers one (for example a read-only key in Neon).

Example source connection strings
postgresql://user:password@host:5432/dbname
mysql://user:password@host:3306/dbname
rediss://default:password@host:6379

A couple of providers do not expose everything through their API. Supabase never returns the project database password, so you paste it once for the project you choose. PlanetScale is different again: Layerbase mints a short-lived read-only password for the database you pick, copies from it, then deletes it.

Auth users come across

If your source database backs an auth system, how the users travel depends on where their credentials live. With Supabase Auth the users and their bcrypt password hashes sit in the database, so they come over intact and nobody has to reset a password. With Neon Auth the passwords live in Stack Auth, not the database, so only profiles migrate and users set a new password on first sign-in. Regular tables migrate normally either way.

Migrating a Redis message queue

Upstash and Vercel KV can back a message queue as well as plain key-value data. A queue can only be migrated into a Valkey database. If you point one of these sources at a Redis target you get the keys and values but not the queue, so create a Valkey database and import there instead. The form tells you this and offers a one-click Valkey create.

How long it takes

The import runs on the server and reports progress live, so you can leave the page open. Small databases finish in seconds; larger ones take a few minutes. When it completes, a create-flow migration drops you on the new database, and a Migrate-tab import refreshes the existing database so its size and tabs reflect the imported data.

If your Neon project had extra branches, Layerbase offers to turn on its own branching after the import rather than replicating them, so you can create instant copy-on-write branches from the migrated database.

If the import fails

Before copying, Layerbase validates the source (it wakes it, checks it is reachable, and sizes it). A bad key, an unreachable host, or a paused project is caught here with a specific error. In the create flow the new database is provisioned first, so if the source check fails you are left with an empty database you can retry from its Migrate tab or delete. Railway sources need public networking enabled on the service, and Algolia needs an Admin key (a search-only key cannot read records or settings).