Skip to content
LayerbaseLayerbase

Migrating a Railway database to Layerbase

4 min readRailwayPostgreSQLDatabasesDeveloper Tools

Railway is a genuinely nice place to deploy an app: push, and your service, database, and networking come up together. The friction shows up on the database side as you grow, in two ways. The bill is usage-metered (you pay for resource-minutes, which is hard to forecast), and your data lives inside Railway's networking, which is convenient until you want it somewhere else.

If you want a database with flat per-instance pricing that isn't tied to where your app deploys, Layerbase Cloud hosts Postgres, MySQL, and Redis/Valkey as managed instances. Railway uses standard engines, so moving is a data copy and a connection-string change, and Layerbase can pull the database across from a single Railway token. You can keep deploying your app on Railway and just move the data; nothing forces an all-or-nothing switch.

Contents

What Actually Changes

Railway's databases are plain Postgres, MySQL, and Redis, so the engines themselves don't change. Two things do:

  • Pricing. Railway meters resource usage (per minute) on top of a plan minimum. Layerbase is flat per instance: predictable regardless of how busy the database is.
  • Networking. Railway databases default to private networking inside your project. To copy the data out (whether by the wizard or by hand), you enable Railway's TCP proxy / public networking on the database service so it's reachable, then turn it back off after. That's the one extra step compared to a database that's already public.

Everything else is standard. Your tables, keys, queries, and client libraries work the same; you change a connection string.

Set Up the Engine Locally with SpinDB

Stand up the matching engine locally first so you can copy into it and verify. SpinDB does it with one CLI, no Docker. (What is SpinDB?)

bash
npm i -g spindb    # npm
pnpm add -g spindb # pnpm

Create whichever engine your Railway database is (Postgres shown; use -e mysql or -e valkey for the others):

bash
spindb create railway-migration -e postgresql --start
spindb url railway-migration
text
postgresql://layerbase:<password>@127.0.0.1:5432/railway-migration

Copy Your Data

The managed wizard (one token)

On Layerbase Cloud, choose Migrating from another platform, pick Railway, and paste a Railway account or team token (Railway, then Account Settings, then Tokens). It lists your Postgres, MySQL, and Redis services; pick one and it provisions a matching Layerbase database and copies the data across server-side. The source must have public networking enabled so the copy can reach it (Railway, your database service, then Settings, enable the TCP proxy); you can disable it again afterward.

By hand

Enable the TCP proxy on the Railway database (above) to get an external connection string, then use the engine's standard dump tool into your local SpinDB instance or a managed Layerbase database:

bash
# Postgres
pg_dump "$RAILWAY_DATABASE_URL" | psql "postgresql://layerbase:<pw>@<host>:5432/app?sslmode=require"

# MySQL
mysqldump --single-transaction --set-gtid-purged=OFF -h <host> -u <user> -p<pw> <db> | \
  mysql -h <layerbase-host> -P <port> -u layerbase -p<pw> --ssl <db>

# Redis (scan + DUMP/RESTORE; see the Upstash guide for the full loop)
redis-cli -u "$RAILWAY_REDIS_URL" --scan | ...

Repoint Your App

Railway injects connection variables (DATABASE_URL, REDIS_URL, and the per-engine PG*/MYSQL* vars). Point them at the Layerbase connection string from your Quick Connect panel:

bash
# Before (Railway-provided)
DATABASE_URL=postgresql://postgres:...@containers-us-west-x.railway.app:1234/railway

# After (Layerbase)
DATABASE_URL=postgresql://layerbase:...@your-host.cloud.layerbase.dev:5432/app?sslmode=require

Your client library doesn't change; these are standard engines on both sides. If your app still deploys on Railway, set the new DATABASE_URL in the Railway service's variables and remove the reference to the Railway-managed database.

What to Test

  • Run your suite against the local copy before cutting production over; standard engines behave identically.
  • Confirm SSL settings. Layerbase endpoints use TLS; make sure your connection string requests it (sslmode=require for Postgres, --ssl for MySQL, rediss:// for Redis).
  • Re-disable Railway public networking once the copy is verified, so the source isn't left exposed.
  • Check connection pooling if you were relying on Railway's defaults; set a sane pool size against the new endpoint.

The Managed Path: Layerbase Cloud

Run the manual copy once to see what moves; when you want it managed, Layerbase Cloud provisions Postgres, MySQL, or Valkey with TLS, backups, and flat pricing, and the Migrating from another platform wizard does the copy from your Railway token. Your app can keep living on Railway, or move; the database is now independent of where you deploy.

Wrapping Up

Moving a Railway database off Railway is mechanical: the engines are standard, so it's a dump-and-restore (or one token through the wizard) plus a connection-string change. The only Railway-specific step is enabling public networking on the source long enough to copy it.

Manage your local instance with SpinDB:

bash
spindb stop railway-migration    # Stop the server
spindb start railway-migration   # Start it again
spindb url railway-migration     # Print the connection URL
spindb list                      # See all your instances

SpinDB handles 20+ database engines, so you can run Postgres, MySQL, and Valkey side by side while you verify each move. Layerbase Desktop wraps it in a GUI on macOS.

Something not working?