---
title: "Prisma Accelerate Is Retiring: Prisma Postgres, Neon or Direct"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-11-03"
category: "Technology"
tags:
  - Prisma Accelerate
  - Prisma Postgres
  - Neon vs Supabase
  - database connection pooling
  - Prisma 7 driver adapter
excerpt: "Prisma Accelerate shuts down on December 1, 2026, and the managed pooling and query caching go with it. Here is what to switch to, what it costs and what to do each week until then."
reading_time: "10 min read"
canonical_url: "https://kanopylabs.com/blog/prisma-accelerate-retirement-prisma-postgres-vs-neon-vs-direct-connection"
---

# Prisma Accelerate Is Retiring: Prisma Postgres, Neon or Direct

## What Is Actually Happening to Prisma Accelerate

Prisma Accelerate, the managed connection pooling and query caching service that sits between your app and your database, is being retired on December 1, 2026. That includes the hosted Accelerate connections that Prisma Postgres databases used, the ones starting with **prisma+postgres://accelerate.prisma-data.net**. After that date those URLs stop working, so any app still using them has to switch to a direct or pooled connection string.

Today is November 3, 2026, which leaves you 28 days. That is enough time if you start this week and not enough if you treat it as a someday ticket. Prisma's own migration docs are clear that the change only affects how your app connects. Your data, your workspace and your plan stay as they are. Nothing needs to be exported or re-modeled.

![Developer at a laptop updating a database connection string in an application config](https://images.unsplash.com/photo-1517694712202-14dd9538aa97?w=800&q=80)

There are two groups of people reading this. The first group runs a Prisma Postgres database and connects through the Accelerate URL. The second group uses the Accelerate extension in front of their own database, on Neon, Supabase, RDS or anywhere else. Both groups have to remove Accelerate before December 1, 2026. The route differs slightly, and so does the amount of cleanup.

## What You Lose When Accelerate Goes

Accelerate did two jobs for you, and you need to know which of them your app depended on.

The first was managed connection pooling. Serverless functions open a lot of short-lived connections, and Postgres handles that badly. Accelerate absorbed the spikes so your database saw a steady, small number of connections. Once Accelerate is gone, that protection is gone with it unless you replace it. This is the part that causes outages, because the app works fine in testing and falls over at the first real traffic spike.

The second was query caching, the **cacheStrategy** argument you could add to a Prisma query. Prisma has said plainly that Prisma Postgres does not offer replacement caching and that it is not on the near-term roadmap. Queries that used to come back from a cache will now hit your database every time. If you cached an expensive dashboard query with a 60 second TTL, expect that query to run on every request until you fix it yourself.

Prisma also documents a smaller side effect. If you ever hit a P6000 error with the message "Worker exceeded resource limits" on Cloudflare Workers, that limit lived inside Accelerate, and switching connection paths removes it.

My take is that the pooling loss is the dangerous one and the caching loss is the annoying one. Most apps that used **cacheStrategy** used it on three or four queries. You can find them with a text search and handle them individually, which we cover below.

## Option One: Stay on Prisma Postgres and Connect Directly

If your database is already on Prisma Postgres, this is the lowest-effort path and the one I would take first. Prisma's guidance gives you two ways to connect without Accelerate, and both keep connection pooling.

### Path A, pooled TCP

For a normal Node.js or Bun server, you generate a pooled connection string and a direct one in the Prisma Console. The pooled string, on a **pooled.db.prisma.io** host, handles app traffic. The direct string handles migrations, introspection and Prisma Studio. In Prisma ORM 7 you install the **@prisma/adapter-pg** driver adapter along with the **pg** package, create a **PrismaPg** adapter with the pooled URL, and pass it to the client. Your **prisma.config.ts** points the CLI at the direct URL. Uninstall **@prisma/extension-accelerate** while you are there.

### Path B, the serverless driver

If you run on the edge or in a TCP-restricted runtime such as Cloudflare Workers, you use **@prisma/adapter-ppg** and **@prisma/ppg** instead. The runtime needs **fetch** and **WebSocket** support. In this path the direct connection string is also the credential the driver uses, which surprises people the first time because the env var looks like the wrong one.

If you are still on Prisma 6, upgrade to 6.19 first. The Prisma 6.19 path works with the same two connection styles but uses the older generator settings, so follow the version-specific steps in Prisma's docs rather than mixing them. One caution from the same docs. Prisma ORM 8 does not use this Accelerate integration, so the Accelerate migration guide does not apply to it, and you should plan the 8 upgrade as its own task after the cutover.

### What it costs

Prisma Postgres bills per operation, where each query counts as one. As of November 2026 the published plans run from a free tier (200,000 operations, 2 GB storage) through Starter at about $10 a month, Pro at about $49 and Business at about $129, with overage rates per million operations that fall as you move up. Database data transfer is unlimited. The number that matters for you is your monthly query count. Without Accelerate caching, that count will go up, so look at it before you pick a plan.

The honest downside is that you are staying with a vendor that just retired a product you relied on. That does not make the replacement bad, but it is a fair input to the decision.

## Option Two: Move to Neon or Supabase With Their Poolers

If you were using Accelerate in front of your own database, or you want out of Prisma's hosting, a managed Postgres provider with a built-in pooler is the cleanest replacement. Both Neon and Supabase ship pooling as a feature, so you get back the job Accelerate did without running anything.

### Neon

Neon prices on usage. At the time of writing the free plan includes 100 compute-hours per project and 1 GB of storage per project, and the paid Launch plan has no monthly minimum, charging roughly $0.11 per compute-hour and $0.35 per GB-month of storage. The Scale plan charges about twice the compute rate. Neon's pooled endpoint supports up to 10,000 pooled connections per compute, which is far more than most products will ever need. It scales to zero when idle, so a small product with spiky traffic often lands in the $5 to $40 a month range. Compute size and how long it stays awake are what drive the bill. If you are weighing Neon against other serverless databases, we compared them in [Neon vs PlanetScale vs Supabase](/blog/neon-vs-planetscale-vs-supabase).

### Supabase

Supabase Pro starts at about $25 a month, with 8 GB of disk per project and a $10 monthly compute credit that covers one Micro instance. Extra projects pay full compute. A Micro instance gives you around 60 direct connections and 200 pooler connections, a Small gives roughly 400 pooler connections, and a Medium around 600. You also get auth, storage and realtime in the same bill, which is a real benefit if you were about to build those anyway and a pointless cost if you were not. The free tier pauses projects after a week of inactivity, so do not run anything customer-facing on it.

### How the Prisma side changes

In Prisma ORM 7 you use the **@prisma/adapter-pg** adapter with the provider's pooled connection string for app traffic, and keep a direct string for migrations. That split is the pattern to remember. The pooled URL is for your running app, the direct URL is for the Prisma CLI. Mixing them up is the most common reason a migration hangs, because poolers in transaction mode do not like the session-level commands migrations use.

The migration itself is a dump and restore. For a database under a few GB it is an afternoon with **pg_dump** and **pg_restore**, plus time to test. Budget a rehearsal on a copy first, then a short write freeze for the real cutover.

## Option Three: Direct Connection Plus Your Own Pooler

Prisma's own guidance for people keeping their database says a direct URL may be fine if you run a long-lived Node.js or Bun server and your database's connection limit covers your workload. That is a legitimate answer for a lot of products. A single Next.js server on a VM or container, or a Fly.io or Railway service, holds a small steady pool, and Postgres is happy with it. Create one Prisma Client instance, reuse it, and set a sensible pool size in the adapter.

Serverless changes the math. Every function instance can open its own pool, so a traffic spike turns into hundreds of connections, and a default Postgres allows around 100. If you are on Vercel functions against RDS or a plain managed Postgres, you need a pooler in the middle.

That means **PgBouncer** or Supabase's **Supavisor**, or the pooler your cloud provider already offers, such as RDS Proxy on AWS. PgBouncer is free software and runs as a tiny container, so the cost is mostly your time, call it a day to set up properly and a few dollars a month to host. Use transaction pooling mode for the app and keep a separate direct connection for migrations. Check your Prisma version's notes on prepared statements, since transaction-mode poolers have historically needed a flag for them.

![Code on a monitor showing database connection and pool configuration](https://images.unsplash.com/photo-1461749280684-dccba630e2f6?w=800&q=80)

My honest view is that running your own pooler is the right call in two cases. You already operate infrastructure and have someone who will own it, or you have compliance reasons to keep the database where it is. If neither applies, a managed pooler from Neon, Supabase or Prisma is cheaper than the engineering hours, and it will not page you at 2 a.m.

If you also have an edge runtime, check this early. Prisma's docs say to confirm your runtime and driver can connect without Accelerate, and if they cannot, move database access to a runtime that can. Do not discover this on November 28.

## Replacing Query Caching

Here is the part nobody has a drop-in answer for. Accelerate's cache is gone and nothing in Prisma replaces it. You have three practical choices, and most apps use a mix.

- **Next.js caching.** If your queries run inside Server Components or route handlers, wrap them with the framework's data cache. In current Next.js you can mark a function with the **use cache** directive, set a cache life and tag it, then revalidate by tag after a mutation. It costs nothing extra and covers most read-heavy pages.

- **Redis, usually Upstash.** Use it when the result is shared across many requests and many servers, or when you need explicit expiry. Upstash is priced per command with a free tier and pay-as-you-go beyond it, which for a small product usually means a few dollars a month. You write a small helper that checks Redis, falls back to Prisma and stores the result with a TTL.

- **Fix the query.** Sometimes the cache was hiding a missing index or an N+1 pattern. Look at the slow ones before you cache anything.

Prisma's migration notes tell you to search for **cacheStrategy**, **withAccelerateInfo**, **$accelerate.invalidate** and **$accelerate.invalidateAll**. TypeScript should flag removed APIs at build time, but untyped code and casts can fail at runtime, so run the text search even if the build passes.

Invalidation is the real work. Accelerate gave you a TTL and a tag-based invalidate call. If you move to Redis, you now own the rule for when a cached value is wrong. Keep TTLs short at first, a minute or two, and only lengthen them once you trust the invalidation. A stale price or stale permission is worse than a slow page.

## A Dated Checklist Before December 1, 2026

Twenty-eight days is tight but workable. Here is the schedule I would run, with the dates in 2026.

![Dashboard showing database connections and query latency during a load test](https://images.unsplash.com/photo-1504868584819-f8e8b4b6d7e3?w=800&q=80)

1. **November 3 to 6.** Inventory. Search the codebase, build scripts and deployment config for **prisma+postgres://accelerate.prisma-data.net**, **withAccelerate**, **accelerateUrl**, **@prisma/extension-accelerate**, **@prisma/client/edge**, **cacheStrategy** and the **--no-engine**, **--accelerate** and **--data-proxy** flags. Write down every match and every environment, including CI.

2. **November 9 to 13.** Decide. Pick one of the three options below, note your peak concurrent connections and your cached queries, and check which Prisma version you are on.

3. **November 16 to 20.** Build and rehearse. Generate the new connection strings, install the driver adapter, remove the extension, and deploy to a preview environment. Run reads, writes and transactions. If you are moving providers, do a full restore rehearsal.

4. **November 23 to 25.** Load test. Watch database connections, timeouts and latency at realistic concurrency, with caching removed. Add Redis or framework caching where the numbers demand it.

5. **November 26 to 27.** Production cutover on a weekday morning, with the team online, not late on a Friday. Keep the old Accelerate credential until the new path is stable.

6. **November 30.** Confirm nothing in production still receives an Accelerate URL, then revoke the old credentials and delete unused secrets.

7. **December 1, 2026.** Accelerate is retired. This should be a non-event.

The buffer between the cutover and the deadline matters. Plenty of teams will cut over on the last weekend, and if your provider has an incident that week you want slack in the schedule.

## Which One for Your Product

Here is how I would map the common situations to a pick.

- **Your database is already on Prisma Postgres and you run on Node.** Stay, and use the pooled TCP path with the pg adapter. It is the smallest change and nothing moves.

- **Your database is on Prisma Postgres and you deploy to Cloudflare Workers or another edge runtime.** Stay, and use the serverless driver adapter. Test it on a preview deploy first.

- **You use Accelerate over a database on Neon or Supabase.** Switch to that provider's own pooled string. You already have the pooler, you were just paying for a second one.

- **You are early stage, cost sensitive, and want auth and storage too.** Supabase Pro at about $25 a month is a sensible home. Neon is better if your traffic is spiky and you want scale to zero.

- **You run one long-lived server on a VM or container.** A direct connection with a well-sized pool is enough. Do not add infrastructure you do not need.

- **You are on Vercel functions against RDS or a self-managed Postgres.** Put PgBouncer or RDS Proxy in front, or move the database to a provider with pooling built in.

- **You leaned hard on cacheStrategy for a heavy read path.** Whatever you pick, plan Redis or Next.js caching as a separate piece of work.

If you are still deciding whether this ORM and database pairing is right for the long term, our [comparison of Drizzle, Prisma and TypeORM](/blog/drizzle-vs-prisma-vs-typeorm-comparison) covers the trade-offs. A vendor retiring a service is a good moment to ask that question, though not a reason to rewrite your data layer in four weeks. Migrate the connection now and revisit the ORM when you have time.

The same rule applies to how we think about stacks generally. For a case study, [Dropify](/work/dropify) went from idea to revenue in 12 weeks on Next.js, Python, PostgreSQL and Vercel, and that pace only works when the database and hosting choices are boring and made early. Kanopy helps founders pick a stack and build the product on it.

## What to Read Next and Who to Call

The retirement is a connection-layer change and you can finish it this month. The bigger lesson is that every managed service in your stack is a dependency with a shutdown risk, so keep the seams clean. Put database access behind one module, keep connection strings in environment variables, and avoid vendor-specific query APIs in your business logic. When a service goes away you change one file.

If you are planning a new product and want to choose the database, hosting and ORM with these risks in mind, start with our guide on [how to build a SaaS platform](/blog/how-to-build-a-saas-platform). It covers the stack decisions that are expensive to change later and the ones that are not.

If your migration is more tangled than a connection string swap, or you want a second pair of eyes on a plan before the cutover, [Book a free strategy call](/get-started).

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/prisma-accelerate-retirement-prisma-postgres-vs-neon-vs-direct-connection)*