Skip to content

Migrating from Render Postgres to Layerbase

3 min readRenderPostgreSQLDatabases

Render is a clean place to deploy a web service, and its managed Postgres has one detail that catches people: free databases expire after 90 days. You get a reminder, and then you either upgrade to a paid plan or the database is deleted. 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 90 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.

Contents

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 90; 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 SpinDB

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

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

spindb create render-migration -e postgresql --start
spindb url render-migration
text
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 SpinDB instance), grab the external connection string from the Render database page and use the standard Postgres tools:

bash
# 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:

bash
# 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 pgvector, pg_trgm, citext, or similar on Render, confirm they're enabled on the new database (CREATE EXTENSION IF NOT EXISTS ...) before the app hits them.
  • 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 90-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.

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 SpinDB:

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

SpinDB 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.

Something not working?