Guide

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. Import into an empty database, and confirm with the checkbox before it runs. A dump-based source (Postgres, MySQL or MariaDB, Redis or Valkey) replaces the target contents, so anything in it is lost. A source read over an API instead (Turso, Cloudflare D1, Algolia) does not clear the target: the copy is added to whatever is there, so a database that already holds data can fail partway or end up with a mix. Use this tab 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.

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, Turso, and Cloudflare D1 work this way. A few need a second value: Upstash needs your account email, PlanetScale needs the service token ID, Algolia needs its Application ID, and Cloudflare D1 needs your account 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).

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.

Migrating from Cloudflare D1

D1 needs your Cloudflare account ID plus an API token that is account-scoped and carries D1 Read. Read is all Layerbase needs, because the migration only issues read statements against your database. A zone-scoped token cannot work, because Cloudflare has no zone-level D1 permission, and a Global API Key is not a bearer token, so it fails authentication. Create the token under My Profile, then API Tokens.

One thing to plan for: the migration does not take your D1 offline, so it keeps serving traffic while the copy runs, but it is also not a point-in-time snapshot. Layerbase pages through your tables, so rows written partway through the migration can land unevenly across tables. Migrate from a quiet database, or pause writes while the copy runs. Row counts are verified once the copy finishes, so an inconsistent copy is reported rather than silent. The migration form shows this before you paste anything.

When the copy finishes you stay on a completion screen that shows that verification: per-table row counts, anything written to mid-copy, and any follow-up the copy needs (a full-text search table is recreated but its content is not copied, so rebuild it). Read it before you archive or delete the D1 database. The list of your D1 databases shows names without sizes, because Cloudflare only reports a size per database through an extra call for each one, which would eat into your account’s shared D1 API rate limit.

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. The libSQL sources (Turso and Cloudflare D1) are the exception: they hold on the completion screen so you can read the row-count verification first, then take you to the database when you are ready.

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

When you paste a connection string, Layerbase validates the source before copying: it wakes it, checks it is reachable, and sizes it. A bad password, an unreachable host, or a paused project is caught there with a specific error. An API-key source has no such pre-check: Layerbase opens it server-side when the run starts, so a bad key, a wrong token scope, or a source it cannot read surfaces as a failed import with the error on the progress screen. Either way, in the create flow the new database is provisioned first, so a source that cannot be read leaves you with an empty database to 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).