# Migrating from Render Postgres to Layerbase

> Render's free Postgres expires after 30 days and the paid tiers climb fast. Here is how to move to managed Postgres on Layerbase with one API key, with no expiry clock and flat pricing.

Published: 2026-06-23
Canonical: https://layerbase.com/blog/migrating-from-render-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](https://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](https://cloud.layerbase.com/create?engine=postgresql) 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](https://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](#what-actually-changes)
- [Set Up Postgres Locally with the Layerbase CLI](#set-up-postgres-locally-with-the-layerbase-cli)
- [Copy Your Data](#copy-your-data)
- [Repoint Your App](#repoint-your-app)
- [What to Test](#what-to-test)
- [The Managed Path: Layerbase Cloud](#the-managed-path-layerbase-cloud)
- [FAQ](#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](https://layerbase.com/docs/cli) (formerly SpinDB) runs it with one CLI, no Docker. ([What is the Layerbase CLI?](https://layerbase.com/docs/cli))

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

lbase create render-migration -e postgresql --start
lbase 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](https://cloud.layerbase.com/create?engine=postgresql), 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:

```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 `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. PostGIS is available on PostgreSQL 18 as a per-database opt-in (`CREATE EXTENSION postgis;`), but only core PostGIS: raster, topology, the tiger geocoder, address_standardizer and SFCGAL are not included. `pgvector` is the exception: we do not ship it, so a database that depends on it does not move as it stands. For embeddings, [Qdrant](/db/qdrant) is a separate engine on the same account, and [pgvector vs Qdrant](/blog/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](https://cloud.layerbase.com/create?engine=postgresql) 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. Core PostGIS comes across on PostgreSQL 18, but its raster, topology, tiger geocoder, address_standardizer and SFCGAL components do not. `pgvector` we do not ship, so that needs 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:

```bash
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](https://layerbase.com/docs/cli), so Postgres can sit next to Redis, Meilisearch, or Qdrant while you verify the move. [Layerbase Desktop](https://layerbase.com/desktop/download) wraps it in a GUI on macOS. Comparing options first? See [which relational database to choose](/blog/which-relational-database).