Vercel Postgres alternatives: own your database in 2026

Short version: Vercel Postgres is gone as a product. Vercel moved every existing store to Neon in December 2024, so what you hold today is a metered Neon project reachable by an ordinary postgresql:// connection string. That makes leaving it a data copy plus one client swap: paste the non-pooling string into a migration wizard (or run pg_dump into psql), then replace the unmaintained @vercel/postgres package with @neondatabase/serverless or a standard pg client. If you want a Postgres you own at a flat price rather than a compute-hour meter, managed Postgres on Layerbase is the closest landing spot, and it speaks the same HTTP protocol the serverless driver already uses.

Vercel Postgres was Vercel's first-party Postgres: Neon underneath, a @vercel/postgres client that worked from the edge, and one bill. It is not a product you can buy anymore. Vercel's Postgres docs say it plainly: "Vercel Postgres is no longer available. If you had an existing Vercel Postgres database, we automatically moved it to Neon in December 2024. For new projects, install a Postgres integration from the Marketplace." Neon's transition guide fills in the timeline: Vercel transitioned all Vercel Postgres stores to Neon's native integration during Q4 2024 and Q1 2025.

So if you still think of your database as Vercel Postgres, what you actually hold is a Neon project billed by the CU-hour. Nothing broke, which is why so many projects never noticed. That makes it a good moment to ask a different question: do you want to keep renting Postgres through a compute meter, or own an instance at a flat price?

If the answer is "own it," Postgres on Layerbase Cloud is a managed instance with flat per-plan pricing. Because the store was always plain Postgres, your data is portable with a single connection string, and the only code change is retiring the deprecated client. The Vercel KV twin of this post covers the Redis side of the same sunset.

Just want it done? Start at layerbase.com/migrate/vercel-postgres. You sign in, the wizard opens with Vercel Postgres already selected, and it copies the schema and data in one read-once pass from the connection string in your project's environment variables. Nothing is written back to the Neon project.

Contents

• What Vercel Postgres actually was
• Where the data can go
• Copy your data
• Swap the client
• What to test
• The managed path: Layerbase Cloud
• FAQ
• Wrapping up

What Vercel Postgres actually was

Vercel Postgres was Neon. Vercel exposed it through a set of environment variables (POSTGRES_URL, POSTGRES_PRISMA_URL, POSTGRES_URL_NON_POOLING, POSTGRES_USER, POSTGRES_HOST, POSTGRES_PASSWORD, POSTGRES_DATABASE) and a @vercel/postgres package that wrapped Neon's serverless driver for edge runtimes. That was the same shape as Neon because it was Neon, and after the December 2024 move it is Neon without the Vercel wrapper.

Three things about the current state are worth knowing before you touch anything:

• The environment variables still work. Neon's guide says existing environment variables, along with the Drizzle, Prisma, and Kysely integrations, continue to work. Your project has not lost its connection.
• The client is unmaintained. @vercel/postgres still works but, per the same guide, is no longer actively maintained by Vercel and will be deprecated. Neon's recommended paths are @neondatabase/vercel-postgres-compat as a drop-in replacement, or @neondatabase/serverless for new code.
• The bill is a meter. Neon's Launch plan is $0.106 per CU-hour and $0.35 per GB-month, with scale-to-zero after 5 minutes. A database that stays warm bills for every hour of the month.

So moving off it is the same as moving any Postgres:

• Your schema and rows copy over with the postgresql:// URL.
• The @vercel/postgres client becomes @neondatabase/serverless (same HTTP shape, works on the edge) or a standard pg client on a Node runtime.
• Flat per-plan pricing replaces the compute-hour meter.

Where the data can go

Because the store was always Postgres, every option below reads the same connection string. The choice is really about who operates the instance and how it bills.

The Marketplace is a real option and I am not going to pretend it is not. It just moves you from one metered vendor to another, and the Vercel invoice is the only thing that stays the same.

Copy your data

The managed wizard (paste your connection string)

On Layerbase Cloud, choose Migrating from another platform, pick Vercel Postgres, and paste the value of POSTGRES_URL_NON_POOLING from your project's environment variables. A -pooler hostname works too: we switch to the direct endpoint automatically before copying, so the migration never runs through the pooler. It reads the schema and data once and writes them into a fresh managed Postgres. The source is never modified and the string is not stored.

If your project was provisioned after the move, the variables may carry Neon's names instead (DATABASE_URL, DATABASE_URL_UNPOOLED). Read your project's actual environment list and take whichever one holds a postgresql:// string.

By hand with pg_dump

That connection string is a normal Postgres endpoint, so the standard tools work directly:

SRC='postgresql://default:<password>@ep-xxxx.us-east-1.aws.neon.tech/verceldb?sslmode=require'
DST='postgresql://layerbase:<password>@<host>.cloud.layerbase.dev:5432/appdb?sslmode=require'

pg_dump "$SRC" --no-owner --no-acl | psql "$DST"

Use the non-pooling host for the dump. A transaction pooler in front of a long pg_dump is how you get a truncated copy with no error message.

Swap the client

The one code change is the client. @vercel/postgres is Neon's serverless driver with a Vercel wrapper, and nobody is maintaining the wrapper.

Before (@vercel/postgres):

import { sql } from '@vercel/postgres'

const { rows } = await sql`SELECT * FROM users WHERE id = ${id}`

After (@neondatabase/serverless, works on Vercel Edge and against Layerbase):

import { neon } from '@neondatabase/serverless'

const sql = neon(process.env.DATABASE_URL!)
const rows = await sql`SELECT * FROM users WHERE id = ${id}`

Two small differences: neon() returns the rows directly rather than a { rows } object, and the connection string comes from whichever variable you choose rather than being read implicitly. Layerbase Postgres implements the same HTTP query protocol, so this exact code runs against a Layerbase connection string with no further changes. The one gap is interactive transactions over WebSocket; sql.transaction() batches work.

Or, on a Node runtime, the plain pg client:

import pg from 'pg'

const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL })
const { rows } = await pool.query('SELECT * FROM users WHERE id = $1', [id])

If your app runs in Node rather than on the edge, this is the simpler path and it has no protocol gaps at all. Drizzle, Prisma, and Kysely all work against either client.

What to test

• Check the return shape. sql from @vercel/postgres returned { rows }; neon() returns the array. Grep for .rows and fix each call site.
• Confirm the variable name. If you renamed POSTGRES_URL to DATABASE_URL, make sure the preview and production environments both carry it.
• Run your migrations against the new database before you point traffic at it. Drizzle Kit and Prisma Migrate both need the direct (non-pooled) string.
• Compare row counts on a few big tables on both sides.
• Use one client per instance, not one per request, especially in serverless.

The managed path: Layerbase Cloud

Worth doing the copy once by hand to see the shape. When you want managed Postgres you own, Layerbase Cloud provisions it with TLS, daily backups, copy-on-write branching, and flat pricing. Free is $0 with no card: 2 databases, 5 GB, sleeping after 15 idle minutes and waking on connect. Solo is $5/month for 2 databases with one always-on and 10 GB. Pro is $15/month for up to 10 databases, 25 GB, 10 branches per database, 30-day rolling backups, and point-in-time restore on always-on Postgres. The Migrating from another platform flow copies your data from the connection string you already have. Off the compute meter, onto an instance that is yours.

FAQ

Is Vercel Postgres still available?

No. Vercel's Postgres docs say "Vercel Postgres is no longer available," and new projects are pointed at a Postgres integration from the Vercel Marketplace instead. You cannot provision a new Vercel Postgres store.

What happened to my existing Vercel Postgres database?

It was automatically moved to Neon in December 2024, as part of a transition Neon's guide dates to Q4 2024 through Q1 2025. Nothing was deleted and nothing broke, but the thing you own is now a metered Neon project without the Vercel wrapper on top.

Does @vercel/postgres still work?

Yes, for now. Neon's transition guide says it still works but is no longer actively maintained by Vercel and will be deprecated. The recommended replacements are @neondatabase/vercel-postgres-compat as a drop-in or @neondatabase/serverless for new code. Either one also works against Layerbase Postgres, which speaks the same HTTP protocol.

Where do I find my connection string now?

In your Vercel project's environment variables. Older projects still carry the POSTGRES_* set; take POSTGRES_URL_NON_POOLING for a migration. Newer Neon-provisioned projects may carry DATABASE_URL and DATABASE_URL_UNPOOLED instead. Read the actual list rather than assuming, and copy the value fresh before you start.

Do I have to rewrite my code to move off Vercel Postgres?

Only the client import, and only in two small places: the import line and the { rows } return shape. Your schema, data, and ORM configuration stay as they are. If you were already on Drizzle or Prisma, the change is the connection string and nothing else.

What should a Next.js app on Vercel use for Postgres now?

Postgres, hosted by someone you choose. Neon if you want the bill inside Vercel, Layerbase if you want a flat price and the rest of the engine catalog on the same account. Best database for Next.js on Vercel has the full shortlist with the pick for each situation.

Wrapping up

Vercel Postgres was Neon, so leaving it is a data copy plus a one-client swap: paste the non-pooling connection string into the wizard (or run pg_dump into psql), then replace @vercel/postgres with @neondatabase/serverless or pg. The payoff is a flat-priced Postgres you control, reachable by the same driver you already use.

Start at the Vercel Postgres migration page, or create an empty Postgres and see whether the meter was buying you anything you miss.