Prisma Postgres alternatives: the plan with neither meter

Short version: Prisma Postgres counts operations. Every create, read, update, and delete is one tick on the meter, whether it is a one-row lookup or a six-table join, and a cached read counts too. Prisma's own comparison posts frame the choice as operations versus Neon's compute-hours, which is a fair framing of the two meters and skips the option of not having one. Layerbase Cloud is that option: Solo is $5/month, Pro is $15/month, and the number of queries your app runs is not on the invoice. If your app is quiet, Prisma's Free plan is hard to beat. If it is chatty, the meter is the bill.

What Prisma Postgres actually is

Prisma Postgres is the hosted database from the company that makes the Prisma ORM. It launched in 2025 as a serverless Postgres with a twist: instead of the usual compute-and-storage meter, it bills on the number of database operations, and it bundles Prisma Accelerate, the global connection pool and query cache that Prisma sells separately for other databases. The console, the ORM, and the database are one product, and if you already write Prisma schema files the setup is about as smooth as it gets.

The database itself is plain Postgres. Since the direct TCP connections shipped, it is reachable by psql, pg_dump, and any driver, not only through the ORM. That matters for what follows, because it means leaving is a normal Postgres migration rather than an export project.

One thing to get out of the way: this post is about the hosted product. prisma dev, PGlite, and the one-connection ceiling is about prisma dev, the local PGlite runner, and the two do not overlap.

The plan numbers

Verified 2026-09-06 from prisma.io/pricing:

Data transfer is unlimited on every plan, which is genuinely good and worth saying. Free includes 50 databases, paid plans include 1,000. Spend limits are on by default on paid plans, so the meter has a ceiling you set.

The definition that makes the meter work, quoted from the pricing page: "An operation is a single action against your Prisma Postgres database, a create, read, update, or delete. A simple write and a complex query with multiple joins each count as one operation, and a cached read counts too."

Read that last clause twice. Accelerate's cache is the feature that makes Prisma Postgres fast from the edge, and a cache hit is still an operation.

The arithmetic

The meter is fair in the sense that it charges for exactly what it measures. The question is whether what it measures tracks what your app costs to run, and for a lot of apps it does not.

A quiet CRUD app never leaves Free. An internal tool with 20 users doing a few hundred requests a day is maybe 50k operations a month. That is a quarter of the Free allowance, with 500 MB of storage and no card. Prisma is a great deal for this app and I will not pretend otherwise.

A chatty app blows through Pro. Take an ordinary web app: 100k requests a day, and each request does 5 operations (a session lookup, the actual query, a couple of related reads, an audit write). That is 500k operations a day, 15M a month. On Pro that is 10M included plus 5M of overage at $2 per million, so $49 plus $10 is $59 a month, before storage past 50 GB. Double the traffic and it is $79. The meter is linear in requests, and requests are the thing you are trying to grow.

An ORM makes operations easy to multiply. Prisma's include is one operation. A loop that calls findUnique per item is N operations. Nothing about the count is visible in the code until the invoice arrives, which is exactly the problem a spend limit solves and exactly the problem a flat plan does not have.

Storage is a second meter. $2.00 per GB on Starter past 10 GB means a 40 GB database on Starter is $10 plus $60, which is more than Pro. The plan boundaries are doing real work, and you will move through them.

None of this is hidden. Prisma publishes every number and puts a spend limit on by default. It is just that the shape of the bill is the shape of your traffic, and the honest comparison is against a bill that is not.

Where operations pricing actually wins

I want to be fair about this because Prisma has picked a model that is genuinely good for a real set of workloads.

• Light traffic, and lots of it. If you have 30 small projects that each do a few thousand operations a month, Free's 50 databases cover all of them for nothing. No flat plan does that.
• Bursty traffic with long quiet stretches. A launch-day spike costs you operations for the spike and nothing for the six quiet weeks around it.
• Edge-heavy apps that benefit from Accelerate's cache. The global cache is part of the product, and for a read-heavy app served from many regions it is the reason to be there.
• A team that lives in the Prisma Console. Schema, migrations, query insights, and the database in one place is a real productivity gain if Prisma is already your ORM.

What Layerbase does differently

No meter. 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, 10 GB, and 3 branches per database. Pro is $15/month for up to 10 databases, 25 GB, every one of the 18 engines on Layerbase Cloud, 10 branches per database, 30-day rolling backups, client-certificate auth on Postgres, and point-in-time restore on always-on Postgres. Fifteen million operations a month costs the same as fifteen.

Prisma ORM keeps working. Prisma against a Layerbase database is Prisma against any Postgres: DATABASE_URL in the schema, or the @prisma/adapter-pg driver adapter if you prefer the adapter path. Migrations, introspection, and Prisma Studio all work. What you give up is Accelerate. There is no global query cache in front of a Layerbase database, and if that cache was carrying your read latency, that is the thing to test before you move.

The Neon HTTP driver, if you are on the edge. Layerbase Postgres implements the Neon serverless HTTP protocol, so @neondatabase/serverless and the Prisma Neon adapter work against a Layerbase connection string from edge runtimes that cannot hold a TCP socket. The one gap is interactive transactions over WebSocket; a standard pg client covers the rest.

Branching, and the rest of the stack. Branches are copy-on-write and part of the plan rather than a line item, and the Redis or the search index next to your Postgres is on the same account.

Stay on Prisma Postgres if

• Accelerate is doing real work for you. The global cache and connection pooling are the product's best feature, and nothing on a flat plan replaces a cache you did not have to build.
• The Console workflow is your workflow. If schema changes, query insights, and the database live in one tab and your team likes it that way, splitting that is a cost.
• You have many tiny databases. 50 free databases is a number I cannot match on Free, and for a fleet of prototypes it is the right answer.
• You want a spend limit rather than a flat price. A meter with a ceiling is a legitimate way to bound cost, and Prisma turns it on by default.

The case for moving is specific: your operation count is growing with your traffic, you do not need Accelerate, and you would rather the bill stayed still.

The move, with real commands

The direct connection is the key. Per Prisma's direct connections docs, the string looks like:

postgres://USER:PASSWORD@db.prisma.io:5432/?sslmode=require

The pooled host is pooled.db.prisma.io; use the direct one for the copy. You get both from Prisma Console: open the database, click Connect to your database, then Generate new connection string. The docs say the direct string works with psql, pg_dump, pg_restore, and the usual GUI clients, which is exactly what we need.

1. Copy the data. The Prisma Postgres migration page takes the direct string and copies the schema and data in one read-once pass. Nothing is written back and the string is not stored. Or by hand:

pg_dump "postgres://<user>:<password>@db.prisma.io:5432/postgres?sslmode=require" \
  --no-owner --no-acl \
  | psql "postgresql://layerbase:<password>@<host>.cloud.layerbase.dev:5432/appdb?sslmode=require"

If your Prisma Postgres string has an empty database name, the database is postgres. Fill it in for pg_dump.

2. Point Prisma at the new database. Two ways, and both are a one-line change.

// schema.prisma
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

DATABASE_URL="postgresql://layerbase:<password>@<host>.cloud.layerbase.dev:5432/appdb?sslmode=require"

Or with the driver adapter, if you were using prisma+postgres:// URLs through Accelerate and want to stay on the adapter path:

import { PrismaClient } from '@prisma/client'
import { PrismaPg } from '@prisma/adapter-pg'

const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL })
const prisma = new PrismaClient({ adapter })

Remove the @prisma/extension-accelerate import and the .$extends(withAccelerate()) call; there is nothing for it to talk to.

3. Run the migrations and verify. prisma migrate deploy against the new database, then row counts on both sides, then run the app for a few days before you delete the Prisma project. The Free plan does not charge for keeping it around.

FAQ

How does Prisma Postgres pricing work?

As of 2026-09-06, Free is $0 with 200k operations and 500 MB, Starter is $10 a month with 1M operations and 10 GB, Pro runs $49 with 10M and 50 GB, and Business is $129 with 50M and 100 GB. Overage is $8, $2, and $1 per million operations respectively, plus $2.00, $1.50, and $1.00 per GB of storage. Data transfer is unlimited on every plan.

What counts as an operation?

Prisma's definition: a single create, read, update, or delete. A simple write and a complex multi-join query each count as one, and a cached read counts too. A Prisma query with include is one operation; a loop of findUnique calls is one per iteration.

Can I connect to Prisma Postgres with psql or pg_dump?

Yes. Direct TCP connections use db.prisma.io:5432 with sslmode=require, and Prisma's docs list psql, pg_dump, pg_restore, and standard GUI clients as supported. The pooled host pooled.db.prisma.io has a 10-minute statement timeout, so use the direct one for a dump.

Does Prisma ORM work against Layerbase?

Yes. It is standard Postgres, so DATABASE_URL in schema.prisma or @prisma/adapter-pg both work, along with Migrate, Introspect, and Studio. What does not carry over is Accelerate: there is no hosted query cache in front of a Layerbase database.

Is this the same as prisma dev?

No. prisma dev is a local Postgres on PGlite for development, with its own limits, and that post covers it. This one is about the hosted Prisma Postgres product.

Is $15 a month really comparable to the $49 Prisma Pro plan?

Not feature for feature. Prisma's Pro includes Accelerate's global cache and 10M metered operations. Pro is $15/month here for up to 10 databases, 25 GB, branching, 30-day backups, and no operation count at all. If the cache is the thing you use, Prisma's number is buying it. If your app is simply busy, the flat number is the one that decides.

The wrap-up

Prisma built a good hosted Postgres and priced it on the thing an ORM is best placed to count. That is a coherent choice, and for quiet apps and fleets of prototypes it is a generous one. For an app whose traffic is growing, the operation count grows with it, and the meter becomes the bill.

Not having a meter is also an option. Start at the Prisma Postgres migration page, or create an empty Postgres, paste the string into schema.prisma, and stop counting.