Migrating from Render Postgres to Layerbase

Short version: Render Postgres is upstream Postgres with no proprietary client or wire protocol, so this is the plainest migration on the list. Paste a Render API key into the wizard at layerbase.com/migrate/render, pick the instance it lists, and the schema and data copy across in one pass; by hand it is pg_dump piped into psql, using Render's external connection string rather than the internal one. Your schema, queries, drivers, and ORM do not change, and the cutover is one DATABASE_URL. Two things to check on the other side: extensions like pg_trgm need enabling on the new database before your app hits them, and pgvector is not one we ship at all, so check your extension list before you start rather than at restore time. What you leave behind is the 30-day expiry clock on Render free databases, so move before that countdown and its 14-day grace period run out, because after that the database and its data are gone.

Render is a clean place to deploy a web service, and its managed Postgres has one detail that catches people: free databases expire 30 days after creation. You get a reminder, then a 14-day grace period to upgrade to a paid plan, and after that the database is deleted along with its data. The paid tiers are fine, but they climb with storage and connections, and for a small app you may just want a Postgres that doesn't run on a countdown.

Layerbase Cloud hosts plain managed Postgres with a free dev tier that doesn't expire after 30 days, on flat per-instance pricing. Render Postgres is standard Postgres, so moving is a data copy plus a connection-string change, and Layerbase can pull the database across from a single Render API key.

Just want it done? Start at layerbase.com/migrate/render. You sign in, the wizard opens with Render already selected, and it lists your Postgres instances so you pick one, then copies the schema and data in one pass: read-once, nothing written back to Render. The rest of this post is that same migration explained step by step, plus the manual path.

Contents

• What Actually Changes
• Set Up Postgres Locally with the Layerbase CLI
• Copy Your Data
• Repoint Your App
• What to Test
• The Managed Path: Layerbase Cloud
• FAQ

What Actually Changes

Almost nothing at the database layer. Render Postgres is upstream Postgres with no proprietary wire protocol or client, so your schema, queries, extensions, and drivers all carry over. What changes is operational:

• No expiry clock. The free database doesn't get deleted at day 30; the dev tier is meant to sit there.
• Flat pricing. Per-instance instead of Render's storage/connection-scaled plans.
• The connection string. Render gives an internal URL (for services in the same Render region) and an external URL. You swap whichever your app uses for the Layerbase one.

That's the whole surface. It's Postgres on both ends.

Set Up Postgres Locally with the Layerbase CLI

Stand up Postgres locally first so you can copy into it and verify before cutting over. The Layerbase CLI (formerly SpinDB) runs it with one CLI, no Docker. (What is the Layerbase CLI?)

npm i -g layerbase    # npm
pnpm add -g layerbase # pnpm

lbase create render-migration -e postgresql --start
lbase url render-migration

postgresql://layerbase:<password>@127.0.0.1:5432/render-migration

Copy Your Data

The managed wizard (one API key)

On Layerbase Cloud, choose Migrating from another platform, pick Render, and paste a Render API key (Render dashboard, then Account Settings, then API Keys). It lists your Postgres instances; pick one and it copies the schema and data into a fresh managed Postgres server-side, no connection-string hunting.

By hand with pg_dump

If you'd rather do it yourself (or copy into the local instance), grab the external connection string from the Render database page and use the standard Postgres tools:

# One-shot copy. Use the EXTERNAL Render connection string.
pg_dump "$RENDER_EXTERNAL_DATABASE_URL" \
  | psql "postgresql://layerbase:<pw>@your-host.cloud.layerbase.dev:5432/app?sslmode=require"

For zero downtime, logical replication works the same as any Postgres-to-Postgres move. There's nothing Render-specific to account for.

Repoint Your App

Change the DATABASE_URL your app reads:

# Before (Render external)
DATABASE_URL=postgresql://user:pass@dpg-xxxx-a.oregon-postgres.render.com/dbname

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

If your app still runs on Render, set the new DATABASE_URL in the service's environment and detach the Render-managed database. Your ORM and queries don't change.

What to Test

• Run your suite against the local copy before pointing production at the new database.
• Confirm sslmode=require is in the connection string; Layerbase endpoints use TLS.
• Check extensions. If you used pg_trgm, citext, pgcrypto, or similar on Render, confirm they're enabled on the new database (CREATE EXTENSION IF NOT EXISTS ...) before the app hits them. pgvector and PostGIS are the exceptions: we do not ship either, so a database that depends on them does not move as it stands. For embeddings, Qdrant is a separate engine on the same account, and pgvector vs Qdrant covers the decision.
• Verify sequences and AUTO_INCREMENT-style serials resumed above your max id after the restore (a clean pg_dump/psql handles this; verify on tables you write to immediately).

The Managed Path: Layerbase Cloud

The manual copy is worth doing once. When you want managed Postgres without the 30-day clock, Layerbase Cloud provisions it with TLS, backups, and flat pricing, and the Migrating from another platform wizard does the copy from your Render API key. A database that stays put.

FAQ

Can I do this without downtime?

Yes, and there is nothing Render-specific about it. A one-shot pg_dump into psql is the simple path and needs a short write pause at the cutover. If you cannot take even that, set up logical replication from Render to the new database the way you would between any two Postgres servers, let it catch up, then switch DATABASE_URL. Both ends are upstream Postgres, so the standard playbook applies.

Does everything in the database come across?

Schema, indexes, constraints, rows, sequences, views, and functions all restore from the dump, because this is Postgres to Postgres. The one thing worth checking by hand is extensions: if you were using pg_trgm, citext, pgcrypto, or similar, run CREATE EXTENSION IF NOT EXISTS on the new database before your app queries anything that depends on them. pgvector and PostGIS we do not ship, so those need a decision before you move rather than a command afterwards. Verify sequence positions too, on any table you write to immediately after the switch.

My Render database is close to its 30-day expiry. What happens?

Free Render databases are deleted 30 days after creation, with a reminder and a 14-day grace period to upgrade before that happens. Copy it out while it is still alive. Once the deletion goes through, the data goes with it and there is nothing left for a migration to read, so this is one of the few migrations with an actual deadline attached.

Which Render connection string do I use?

The external one. Render gives you an internal URL that only resolves for services inside the same Render region, which means it cannot be dialed from your laptop or from our side, and an external URL that can. The API-key path skips this question entirely: we list your instances and connect for you.

Can I keep running my app on Render?

Yes. Set the new DATABASE_URL in the Render service's environment and detach the Render-managed database. Your web service keeps deploying exactly as it does now; the only thing that changed is which host it opens a connection to.

Wrapping Up

Leaving Render Postgres is the standard Postgres move: it's upstream Postgres, so pg_dump/psql (or one API key through the wizard) plus a connection-string change is the whole job. The difference you feel afterward is the absence of the expiry countdown and a predictable bill.

Manage your local Postgres instance with the Layerbase CLI:

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

The Layerbase CLI handles 20+ database engines, so Postgres can sit next to Redis, Meilisearch, or Qdrant while you verify the move. Layerbase Desktop wraps it in a GUI on macOS. Comparing options first? See which relational database to choose.