Neon serverless Postgres: architecture, pricing, use cases, and tradeoffs
Many conventional PostgreSQL deployments keep compute running continuously and pair it with provisioned storage. Isolated test environments often require snapshots or full copies, although the exact architecture varies by provider.
Continuously running compute can be a poor fit for intermittent traffic and temporary preview environments.
Neon separates stateless Postgres compute from a distributed storage layer. This separation enables scale-to-zero compute, rapid database branching, and usage-based pricing.
The decision to adopt Neon depends on whether the compute lifecycle, copy-on-write branching, and proxy-routed connection model fit your application better than conventional managed Postgres or a broader backend platform.
TL;DR
- Neon fits teams that need fast database branching, preview environments, support for intermittent workloads, or AI/Postgres prototyping.
- Neon separates stateless compute from durable storage, enabling scale-to-zero and copy-on-write branches.
- Validate cold starts, SNI routing, PgBouncer transaction pooling, ORM behavior, and branch governance before production use.
- Compare alternatives when a measured requirement is decisive: AWS-native operations, full infrastructure control, local NVMe with the required replication and durability settings, or a dedicated analytical path after OLTP and reporting contention appears.
What is Neon serverless Postgres?
Neon is a fully managed, serverless PostgreSQL database built on a custom storage architecture. Its engineering documentation now calls the database Lakebase Postgres. It separates Postgres compute from distributed storage built around write-ahead logs (WAL), safekeepers, pageservers, and durable object storage.
The Neon backend reached general availability in September 2026 with Object Storage, Functions, Managed Better Auth, and AI Gateway alongside the database. Teams can use those services or external alternatives for adjacent application requirements. The PostgreSQL compute primarily serves transactional workloads.
Neon manages infrastructure, compute lifecycle, storage durability, and branching. Customers remain responsible for schema design, indexing, query tuning, access control, connection routing, retries, branch data governance, and cost controls.
The selected plan determines available controls. Free requires suspension after five idle minutes; Launch can disable that timeout; Scale can configure it. Scale also adds IP allowlisting and private networking.
How does Neon work?
Neon resource hierarchy and connection paths
Neon environments are structured around these configuration objects and connection paths.
- Project: The top-level container for a database environment, holding all associated branches, computes, databases, roles, and settings.
- Branch: An isolated, copy-on-write timeline of the database state. You can create branches from other branches or from a specific point in time in the storage history.
- Database: A standard Postgres database residing inside a branch.
- Role: A Postgres role for authentication, authorization, and connection management.
- Compute: A Postgres instance attached to a branch. The compute executes queries, manages memory caches, and handles sessions, but holds no permanent durable state.
- Endpoint: The connection target for a compute. Endpoints are available as direct or pooled connections.
- Connection proxy and TLS SNI routing: Neon routes PostgreSQL connections through a proxy that identifies the correct tenant compute from the TLS Server Name Indication (SNI). Clients must support SNI. Legacy libpq builds, older Django configurations, and some desktop tools require client upgrades or explicit endpoint ID connection options to prevent "The endpoint ID is not specified" errors.
- Direct endpoint: The standard PostgreSQL port for administrative operations, schema migrations, pg_dump, long-lived sessions, and workflows requiring session-level Postgres features.
- Pooled endpoint: A PgBouncer-backed connection path using transaction pooling, designed for applications with many short-lived client connections.
- HTTP/WebSocket serverless driver paths: Custom driver connections for JavaScript, edge, and serverless runtimes where persistent TCP connections are restricted or inefficient.
- Read replica: A read-only compute endpoint attached to a branch to isolate read traffic.
Core Neon architecture components and boundaries
The Neon architecture divides responsibilities between execution and durable state. The Postgres compute node handles query execution, in-memory caching, sessions, and supported extensions.
Safekeepers receive the WAL stream from the compute node and ensure durable acceptance. Pageservers serve database pages to the compute node on demand and reconstruct page state from the underlying object storage history. Object storage retains the long-term immutable history required by the storage layer.
Compute nodes maintain the cache and execution responsibility, but all durable state belongs to the networked storage layer.
What happens during a Neon transaction?
During a write transaction, the Postgres compute executes the query and streams the resulting WAL to the safekeepers. Commit acknowledgment depends on the storage and WAL durability path, not on a local filesystem fsync.
Reads check Postgres shared buffers, then Neon's Local File Cache where enabled. A miss requires a network request to the pageserver. Fixed computes of 18 CU or more disable the file cache and allocate more memory to shared buffers.
When you create a branch, the system points a new timeline to an existing point in the storage history. Copy-on-write avoids an immediate full copy. Branch storage charges depend on divergence and retention; even an unchanged child branch can incur root-branch storage charges once it falls outside the history window.
What Neon's separated compute and storage design enables and constrains
Neon's architecture affects compute lifecycle, branching, storage latency, and connection behavior:
- Separated durable storage allows computes to suspend, resize, or restart without moving a physical database volume, so computes can scale to zero.
- Copy-on-write history allows rapid branch creation, enabling CI/CD pipelines and preview environments to use production-like state quickly.
- The networked storage path means cache misses require a network request to the pageserver. Teams must test cold-cache latency and disk-heavy queries carefully.
- Proxy-routed connections demand SNI-capable clients or explicit endpoint identifiers, requiring connection testing for older ORMs, tools, and CI images.
- PgBouncer transaction pooling does not preserve arbitrary session state or SQL-level PREPARE across transactions; protocol-level prepared statements are supported.
What are Neon's key capabilities?
Database branching for preview environments
Neon creates isolated, copy-on-write branches for development, staging, and migration rehearsals. Branching fits pull request environments, destructive schema migration testing, and reproducing production bugs against accurate data.
One team using Neon reported that separate development, staging, and test branches reduced friction between developers. An April 2026 Hacker News commenter also described returning to Neon for branching after trying another provider.
The primary constraints involve data governance and cost. Branches containing sensitive production data require strict masking rules or synthetic data substitution. Over time, abandoned branches and retained history increase storage, demanding automated retention policies and cleanup.
Scale-to-zero compute and autoscaling
Neon supports fixed-size and autoscaling compute. Eligible idle computes can suspend while durable data remains in storage, stopping compute charges. Scale-to-zero fits intermittent applications, internal tools, and preview databases with extended idle windows.
The primary constraint is wake-up latency. Resuming a suspended compute takes time, which can trigger client-side connection timeouts. In a February 2025 account of a personal Django project on Neon Free, the author reported a 12-second first request, an improvement after changing providers, and a separate N+1 fix for the admin page. That request time did not isolate database wake-up latency. Measure the suspended-to-first-query path on the selected plan.
Scale-to-zero controls apply to computes up to 16 CU. Free has a mandatory five-minute idle timeout. Launch retains five minutes but can disable suspension; Scale supports settings from one minute to always on. Larger fixed computes remain active.
Connection pooling, PgBouncer, and serverless connection paths
Neon provides multiple connection strategies: direct endpoints, pooled endpoints, and serverless HTTP/WebSocket drivers. Pooled endpoints use PgBouncer in transaction pooling mode to handle high-fanout serverless functions and web applications with frequent, short-lived requests.
SQL-level PREPARE/EXECUTE and other session-bound state are not portable across transactions, while Neon's PgBouncer path supports protocol-level prepared statements. Use a direct endpoint for stable-session operations and validate the deployed ORM version.
Runtime placement also matters. In an Expo discussion, a developer described using Neon across several projects through Expo's server-side API routes. That setup keeps the database connection in server code rather than the mobile client.
Read replicas and read-only compute endpoints
Neon offers read-only compute endpoints for routing analytical or heavy read traffic away from the primary write compute. Users still create read-replica compute endpoints, but those computes attach to shared storage without copying the full dataset. WAL reaches replicas asynchronously, so read-after-write behavior must be tested.
Read replicas fit read-heavy dashboards, API query endpoints, and reporting tasks. Teams must validate read-after-write expectations, replica freshness, cache warm-up behavior, and the cost impact of running additional active compute hours.
What is Neon used for?
Creating branch-based preview environments
Separate branch computes isolate query execution for pull requests and migration testing without copying the full database. CI/CD automation must create, tag, scrub, and delete those environments reliably; production-derived data still requires masking and access controls.
Running intermittent, bursty, and serverless applications
Neon's autoscaling and scale-to-zero mechanisms fit applications with cyclical usage or long idle windows. The cost benefit depends on actual suspension time, and the application must tolerate resume latency and connection retries.
AI and RAG prototyping with Postgres and pgvector
AI applications often need disposable environments for experiments with embeddings, retrieval-augmented generation (RAG) pipelines, and vector indexing. Neon supports extensions such as pgvector, while branching isolates experiments safely.
Vector workloads demand significant memory and cache resources. Teams must test representative embedding volumes, index choices, and query latency under realistic concurrency.
Provisioning development and test databases quickly
Disposable databases can reduce the need to manage local Postgres containers or share a staging cluster. Neon's projects, branches, and API-driven endpoints provide repeatable provisioning workflows.
A Next.js developer who had used both Neon and Supabase preferred Neon with Drizzle for keeping schema definitions in the codebase and iterating in TypeScript. Drizzle also works with Supabase.
Before scaling this pattern, standardize environment naming, credential rotation, developer permissions, and cleanup automation.
What should you know before using Neon in production?
Reliability and failure handling in Neon
Neon's separated compute and storage model shifts how failures behave compared to single-host deployments. Compute lifecycle events, storage-path network requests, and point-in-time recovery operate differently than traditional local-disk failovers.
| Production concern | Neon behavior to account for | Application responsibility | What to test |
| :---- | :---- | :---- | :---- |
| Compute restart, manual resize, or resume | Restarts and manual size or autoscaling-bound changes disconnect sessions. Automatic autoscaling preserves them. Resume can delay new connections. | Reconnect gracefully, retry safe operations, and enforce write idempotency. | ORM pool recovery, retry limits, cold starts, and manual configuration changes. |
| Transaction interruption | A lost connection can leave the client uncertain whether a transaction committed. | Handle commit uncertainty and implement duplicate-prevention logic. | Idempotency keys and transaction retry boundaries. |
| Storage-path network latency | Cache misses require networked pageserver requests, surfacing latency during heavy un-cached reads. | Avoid assuming local-disk latency guarantees for cache misses. | Cold-cache read latency, heavy sequential scans, and block I/O behavior. |
| Point-in-time recovery (PITR) | Instant restore restores a root branch in place, affecting every database on it. Connection details stay unchanged; the previous state becomes a backup branch. Existing connections are interrupted. | Select the recovery point, verify restored data, and reconnect clients. | Restore rehearsals, branch-wide impact, data verification, and connection recovery. |
In two May 2025 incidents, Neon reported 5.5 hours of impaired database creation and startup in AWS us-east-1; running databases were unaffected. Neon addressed IP allocation and capacity constraints. The incidents illustrate why startup availability matters separately from running-query availability. Review regional incident history and decide whether production computes should suspend.
Security, permissions, and branch data governance
Neon encrypts data in transit and at rest. Among its self-service plans, Scale includes IP allowlisting and private networking; Launch does not. Private networking uses AWS PrivateLink and requires the application and database to be in the same AWS region.
PostgreSQL roles, schema privileges, and row-level security operate natively. Configuring them remains the customer's responsibility.
Branch governance requires rules for who can copy production data and how it is masked. In an April 2026 engineering account, a team pulled back from production-derived pull-request branches because masking rules could miss new columns or JSON fields; it preferred synthetic data until masking coverage could be enforced. Neon's anonymization feature applies static masking rules to specified tables and columns. Teams still own rule coverage, credentials, permissions, and branch cleanup.
Session semantics and ORM integration
Session advisory locks, LISTEN/NOTIFY, temporary tables that must survive across transactions, and other stable-session features belong on a direct endpoint.
For Prisma, current Neon guidance specifies a pooled application URL and a direct URL for CLI schema operations, including prisma migrate and prisma db push.
A suspended compute can exceed a client's connection timeout and surface an error such as Prisma P1001. In 2025 replies to a Prisma discussion, increasing connect_timeout helped some users but not others. Measure resume latency against the configured timeout, then test bounded retries only for operations that are safe to retry.
Monitoring, maintenance, and scale-to-zero blockers
The Neon console provides visibility into CPU, memory, storage, connections, and basic Postgres telemetry. Teams remain responsible for query tuning, index optimization, and slow-query analysis using standard tools like pg_stat_statements.
Repeated connection requests and queries can prevent scale-to-zero. An idle open connection alone does not keep compute active, but pool validation queries, scheduled jobs, and database health checks can.
One SaaS founder reported a \$157 monthly bill and attributed unwanted activity to workflow automation, an AI editor's database integration, and application polling. Audit those clients and queries alongside the autosuspend setting.
Adoption requirements and exit constraints
Adopting Neon requires updating database connection strategies to handle direct, pooled, and serverless driver endpoints appropriately. Migration involves standard dump and restore processes, logical replication, or CSV imports, depending on database size and downtime tolerance.
Postgres schema and data remain portable, while Neon-specific integrations can require rework. In a February 2026 Replit development-database migration, the author reported that data, row-level security policies, and functions survived and TCP connections worked. Code using Neon's HTTP serverless driver needed a replacement. Branching automation and compute-lifecycle assumptions also need review before an exit.
How much does Neon cost?
Pricing model and cost drivers
As of October 2026, Neon's self-service plans bill by resource consumption with plan-specific allowances and controls. Pricing changes since August 2025 mean older invoices reflect different rates or minimums; use the current pricing page for estimates.
| Plan area | What it includes | Why it matters |
| :---- | :---- | :---- |
| Plan | Self-service plans use usage-based pricing, while included allowances and features vary by plan. | Determines feature access, support, and included usage. |
| Compute | Compute Unit (CU) hour pricing, driven by actual compute size and active time. | Determines the compute portion of the bill for active and always-on workloads. |
| Storage and history | GB-month pricing for stored data, branch deltas, and retained restore history. | Creates ongoing charges even when compute is suspended. |
| Additional branches and data transfer | Included allowances and any additional charges depend on the current plan. | Matters for branch-heavy workflows, exports, and cross-cloud traffic. |
| Limits and security | Branch allowances, compute sizes, monitoring retention, IP allowlisting, and private networking vary by plan. | Determines whether the required production controls are available. |
Compute charges follow actual CU size multiplied by active time. The autoscaling maximum caps possible usage but is not billed capacity; background activity can prevent idle suspension and increase CU-hours.
Paid-plan allowances also differ from Free. In May 2026, one Launch customer reported that Free's compute allowance did not carry over. Check the selected plan's included usage before extrapolating from a Free project.
Branching is lightweight at creation, but divergent writes and active branch computes incur ongoing fees.
Cost examples for bursty and sustained workloads
Bursty preview-environment scenario: For short-lived pull-request branches, calculate the cost from active compute time, compute size, storage, restore history, branch usage, and data transfer. A branch that is active only during testing and then suspends may consume fewer CU-hours than an equivalent always-on staging instance.
Sustained OLTP scenario: A continuously active compute accrues CU-hours without idle savings. Compare its monthly compute and storage costs against a fixed-size managed Postgres instance. In August 2025, OpenSecret cited rising usage-based costs among its reasons for moving four databases supporting an always-on application to PlanetScale's fixed-price service.
For one smaller deployment, a December 2025 account from a user with two active projects reported a \$38 monthly bill, considered the pricing reasonable, and cautioned that egress could add up.
What makes Neon costs rise?
Pool validation queries, pg_cron jobs, or database health checks increase costs when they keep computes active.
Leaving scale-to-zero disabled for development endpoints, allowing branch sprawl without cleanup policies, and retaining extensive history windows on high-write databases inflate storage and compute bills.
Large data exports, analytics pipelines, or cross-region application traffic will also drive up network egress charges.
What are Neon's limitations and tradeoffs?
Networked storage can increase cold-cache latency
Reads that miss shared buffers and the Local File Cache, where enabled, require a network request to the pageserver. Fixed computes of 18 CU or more rely on larger shared buffers instead of the file cache. End-to-end latency depends on the working set, compute size, query shape, and compared storage system.
Teams should first test cold-cache latency and disk-heavy queries against workload targets. Consider a configuration or architecture change only when those measurements show that the current approach cannot meet those targets.
Serverless lifecycle changes connection and retry assumptions
Applications must handle resume latency, interrupted sessions, and bounded reconnects. Keeping compute active removes suspension-related wake-up delays and idle savings; it does not remove other connection failure modes.
Troubleshooting accounts identify several possible causes: connections accumulating during NestJS hot reload in May 2026, network problems addressed with VPN or DNS changes in a Prisma thread, and Node.js address selection in August 2026. Diagnose the connection path and application behavior before attributing an error to Neon.
PgBouncer transaction pooling changes session semantics
Neon's built-in pooling multiplexes traffic efficiently but does not preserve arbitrary session state across transactions. Applications can route session-dependent operations to the direct endpoint instead of abandoning those features entirely.
Proxy routing and SNI require compatible clients
The ingress routing architecture requires TLS SNI. Legacy libpq installations, older ORMs, CI pipeline containers, and some database GUI tools fail to connect without explicit endpoint parameters.
Validate all operational scripts and runtime environments before migration.
Heavy analytics and always-on workloads may reduce Neon's fit
Heavy aggregations and analytical scans executed on the same PostgreSQL compute compete with transactions for resources. Neon's read replicas isolate query execution on separate computes; moving reporting traffic requires application routing.
Continuous, always-on production traffic nullifies scale-to-zero savings. When measurements show that reporting load causes transactional requests to miss their latency target, teams should evaluate a dedicated analytical system.
Managed service boundaries limit low-level PostgreSQL control
Neon does not provide arbitrary operating system access, custom compiled extensions, deep kernel tuning, or direct filesystem control. Applications requiring niche OS dependencies, highly specialized replication setups, or custom infrastructure architectures should evaluate self-managed PostgreSQL.
How does Neon compare with Supabase, Aurora, self-managed PostgreSQL, and ClickHouse Managed Postgres?
Compare alternative deployment models based on which specific backend, AWS-native, infrastructure-control, or I/O requirement outranks serverless branching.
| Decision baseline | Prefer it when | What changes relative to Neon | Decision trigger |
| :---- | :---- | :---- | :---- |
| Supabase | The team wants Supabase's Postgres, Auth, Storage, Realtime, and Edge Functions workflows. | Both are backend platforms: Supabase centers its established application-service bundle around each Postgres project, while the Neon backend centers its branching Postgres model and adds Object Storage, Functions, Managed Better Auth, and AI Gateway. | Choose Supabase when its Postgres, Auth, Storage, Realtime, and Edge Functions workflows are decisive; choose Neon when branchable database and backend primitives plus Neon's compute lifecycle fit the application better. |
| Amazon RDS or Aurora | The organization standardizes on AWS operations, procurement, networking, governance, and compliance workflows. | AWS-native integration, IAM alignment, and established VPC patterns dictate the operational model. | Choose RDS/Aurora when AWS alignment, existing commitments, or enterprise operational standardization outweigh database branching. |
| Self-managed PostgreSQL | The team requires full control over the OS, specialized extensions, storage layout, custom backups, replication, or specialized tuning. | Operational ownership shifts to the customer, encompassing HA, patching, monitoring, security, and failover mechanics. | Choose self-managed Postgres when total infrastructure control, legal compliance, or extension requirements outweigh managed-service convenience. |
| ClickHouse Managed Postgres | Sustained, performance-critical OLTP calls for always-on compute and local NVMe, or a separate ClickHouse analytical service. | Local NVMe-backed Postgres offers no standby, one asynchronous standby, or two synchronous standbys. Replication to a separately provisioned ClickHouse service is asynchronous, so the analytical copy is eventually consistent. | Evaluate local NVMe with the standby configuration the application requires. Choose this model when measured transactional performance or the separate analytics path matters more than serverless branching. |
How should you evaluate Neon for your workload?
1. Define pass/fail criteria: Set targets for suspended and warm latency, connection handling, data governance, and monthly costs.
2. Provision a representative environment: Import schema and data, configure runtime and migration roles, and create a test branch.
3. Select connection paths: Use direct endpoints for session-dependent tools, pooled endpoints for short application transactions, and supported HTTP/WebSocket drivers for edge runtimes. Test legacy clients for SNI compatibility.
4. Validate ORM and migration tooling: Follow Neon's Prisma guidance: pooled connections for application queries, direct connections for prisma migrate and prisma db push. Test the deployed versions.
5. Test lifecycle and recovery: Compare suspended and warm query paths, bound safe retries, and rehearse restores. Confirm the plan supports the required suspension settings.
6. Implement branch governance: Automate creation, masking, retention, and deletion. Test replica freshness and cache warm-up if using read replicas.
7. Establish the escalation owner: Confirm support responsibilities across providers. In a July 2025 Azure-hosted Neon account, the author credited Neon's support with resolving the issue after coordination with Azure complicated troubleshooting.
8. Model costs and decide: Include compute size and active time, storage, history, branches, and egress. If continuous activity removes idle savings, re-model the economics against fixed-size managed options. Evaluate alternatives when measured latency, tooling, governance, or cost requirements remain unmet.
Conclusion: Is Neon right for your team?
Neon fits PostgreSQL teams that need branch-based development workflows, fast preview environments, elastic compute, and idle-time savings. It supports AI prototyping and pull-request automation when rapid environment provisioning and an idle-time compute model are priorities.
The decision changes when your workload demands predictable warm performance, session-heavy Postgres semantics, a locally attached storage architecture, extensive OS-level customization, or heavy analytical capabilities that disrupt OLTP latency.
Proceed if measured connection behavior, data governance, and pricing fit your requirements. Disabling scale-to-zero does not by itself disqualify Neon because fixed-size and autoscaling always-active computes remain available. For sustained, performance-critical OLTP, compare ClickHouse Managed Postgres using the standby configuration the application requires and representative queries. Evaluate its separately provisioned ClickHouse analytics path when reporting isolation is decisive.
Frequently asked questions about Neon
What workloads is Neon best for?
Neon fits preview environments, branch-based development, intermittent applications, serverless workloads, and AI/Postgres prototypes when fast provisioning and scale-to-zero reduce cost or operational friction.
Is Neon suitable for production?
Yes, Neon supports production workloads. Production deployments require appropriate compute sizing, connection routing, retry logic, branch data governance, and cost modeling. Configure autoscaling limits if autoscaling is enabled.
Does Neon scale to zero?
Yes, eligible computes up to 16 CU can suspend, stopping compute charges while storage and other applicable charges continue. Free requires a five-minute idle timeout; Launch can disable it; Scale can configure one minute to always on. Repeated connection requests and background queries can prevent suspension; an idle open connection alone does not.
Should I use Neon's direct or pooled connection string?
Use the direct connection for migrations, admin tools, dumps, and session-dependent workflows. Use the pooled PgBouncer connection for high-concurrency applications with short transactions after validating transaction-pooling compatibility.
Does Neon work well with Prisma?
Yes. Neon's current Prisma guide uses a pooled URL for application queries and a direct URL for prisma migrate and prisma db push. Test suspended-compute wake-up latency against Prisma's connection timeout, and add bounded retries only for operations that are safe to retry.
Is Neon suitable for analytics workloads?
Neon supports operational reporting, and read replicas can move analytical queries onto separate compute. Heavy scans on the primary can compete with transactions. Evaluate a dedicated analytical database when query latency, concurrency, freshness, or total compute cost remains unsuitable after assessing Neon's read-replica approach.
How can I keep Neon costs under control?
Control costs by deleting unused branches, limiting retained history, auditing background jobs that prevent suspension, setting appropriate autoscaling limits, and comparing always-on compute costs against fixed managed Postgres options.
Is Neon branching safe for production data?
Branching is useful, but branches created from production data require governance. Use masking, access controls, retention policies, and automated cleanup to prevent sensitive data exposure and branch sprawl.
When should I not use Neon?
Consider alternatives when a tested requirement cannot be met, such as unsupported OS-level control, session-bound behavior that cannot use direct endpoints, or cold-cache and analytical latency outside the workload's target. Continuous traffic alone is not a disqualifier; it removes scale-to-zero savings but can still use autoscaling.
How is Neon different from Aurora Serverless?
Choose Neon when fast branching, preview databases, and scale-to-zero Postgres are decisive for your workflow. Choose Aurora when AWS-native networking, IAM, procurement, or enterprise governance is decisive.
6 reactions
Prisma 8 vs Prisma 7: Should You Upgrade? A Tested Migration Guide
Heads up if any of your projects, CI jobs or Dockerfiles run npm install prisma without a version pin: since August 2026 that installs a Prisma 8 release candidate. I migrated a Prisma 7 app on PostgreSQL 17 side by side, and this is what I found.
Prisma 8 is a rewrite of Prisma ORM, not a version bump. The schema becomes a contract, prisma generate becomes prisma contract emit, @prisma/client is replaced by @prisma/orm-postgres, and queries are chained (db.orm.public.User.where(...).all()). It is still a release candidate, but since August 2026 npm install prisma installs it.
That last fact is the urgent part. Any Prisma 7 project, CI job or Dockerfile that installs prisma without a version now gets a CLI with no generate, migrate or db push. I upgraded a real Prisma 7 app on PostgreSQL 17 with the official side-by-side path, and this guide gives the commands, the output, two gotchas the docs don't spell out, and a clear answer on whether to move now. Facts are cited to the Prisma ORM release status page.
What is Prisma 8?
Prisma 8 (Prisma ORM 8) is the next major version of Prisma ORM, a typed data layer for TypeScript. You describe models in a contract file, prisma contract emit writes contract.json and contract.d.ts, and you query through a db client from @prisma/orm-postgres. There is no generated PrismaClient, and migrations are TypeScript files you can review.
Key facts on October 17, 2026:
| | Prisma ORM 7 | Prisma ORM 8 |
| --- | --- | --- |
| npm tag | prisma@prev (7.10.1) | prisma@latest (8.0.0-rc.23) |
| Status | Stable, supported | Release candidate, GA "expected in October 2026" |
| Runtime package | @prisma/client + a driver adapter | @prisma/orm-postgres (8.0.0-rc.18) |
| Schema file | schema.prisma | contract.prisma (first line // use prisma-8) |
| Codegen | prisma generate | prisma contract emit |
| Queries | prisma.user.findMany({ where }) | db.orm.public.User.where(...).all() |
| Migrations | migrate dev / migrate deploy (SQL) | migration plan / db migrate (TypeScript) |
| Databases | PostgreSQL, MySQL, SQL Server, SQLite, MongoDB, CockroachDB | PostgreSQL; MongoDB early access; SQLite experimental |
| Node.js | 20.19+, 22.12+ or 24+ | 22.18+, 24.11+ or 26+ |
| TypeScript | 5.4+ | 5.9+ |
The CLI and the library are versioned separately, so prisma 8.0.0-rc.23 and @prisma/orm-postgres 8.0.0-rc.18 are a matching pair. Prisma says "any two latest versions work together."
Is Prisma 8 stable? When is the release date?
No, not yet. Prisma 8 is a release candidate, and Prisma's release status page says general availability "is expected in October 2026." On October 17, 2026 the newest builds were prisma 8.0.0-rc.23 (published October 15) and @prisma/orm-postgres 8.0.0-rc.18 (October 14). Prisma warns that "some details of the API may still change."
Two support dates follow from the release:
- Prisma ORM 7 keeps receiving bug fixes and security updates "for 18 months from the day Prisma ORM 8 reaches general availability."
- Prisma ORM 6 receives security patches only until November 19, 2026.
So there is no rush to leave Prisma 7, but Prisma 6 projects should move to 7 now.
Why does npm install prisma install Prisma 8?
Because Prisma moved the npm latest tag to Prisma 8 while it is still an RC. Prisma's August 28 changelog says the release "makes Prisma 8 available through prisma@latest." Prisma 7 is now prisma@prev. A Prisma 7 project that installs prisma without a version range gets a CLI that cannot read its workflow.
I ran the old commands with the Prisma 8 CLI in a Prisma 7 project:
$ npx prisma generate
✘ [CLI.UNKNOWN_COMMAND] No command registered for `generate`
$ npx prisma migrate deploy
✘ [CLI.UNKNOWN_COMMAND] No command registered for `migrate`, did you mean `migration`?
$ npx prisma db push
✘ [CLI.UNKNOWN_COMMAND] No command registered for `push`, did you mean `update`?
Do this today, even if you never upgrade: pin both packages, then grep your CI, Dockerfiles and scripts for npx prisma and prisma@latest.
{
"devDependencies": { "prisma": "^7" },
"dependencies": { "@prisma/client": "^7" }
}
Anywhere a command runs without a lockfile, write npx prisma@7 migrate deploy instead of npx prisma migrate deploy. If you build images with a multi-stage Dockerfile like the one in my Next.js Dockerfile guide, the npm ci step respects the lockfile; a separate npx prisma ... line in a later stage does not.
What changed in Prisma 8?
Almost everything you type. The schema is a contract, codegen is contract emit, the client is built in src/prisma/db.ts, queries are chained, migrations are TypeScript packages tracked by a hash marker in the database, and several Prisma 7 features ($extends, nested updates, increment, JSON filters, P2002 codes) are missing. Your database tables and data do not change.
Commands
| Prisma 7 | Prisma 8 |
| --- | --- |
| prisma generate | prisma contract emit |
| prisma migrate dev | prisma db update, or prisma migration plan + prisma db migrate |
| prisma migrate deploy | prisma db migrate |
| prisma db push | prisma db init (empty database), then prisma db update |
| prisma db pull | prisma contract infer |
| prisma format | prisma contract format |
| prisma migrate reset, prisma db seed, prisma studio | None in the Prisma 8 CLI |
Queries
| Prisma 7 | Prisma 8 |
| --- | --- |
| prisma.user.findMany({ where: { active: true } }) | db.orm.public.User.where({ active: true }).all() |
| findUnique / findFirst | .where(...).first() (returns null) |
| select: { id: true } | .select("id") |
| include: { posts: true } | .include("posts") |
| orderBy: { id: "asc" } | .orderBy((u) => u.id.asc()) |
| take / skip | .limit(n) / .offset(n) |
| create({ data: {...} }) | .create({...}) (no data wrapper) |
| contains: "ali" / mode: "insensitive" | .like("%ali%") / .ilike("%ali%") |
| $transaction(async (tx) => ...) | db.transaction(async (tx) => ...) with tx.orm |
| $disconnect() | db.close() |
public is the PostgreSQL schema the table lives in. The full mapping is in Prisma's Coming from Prisma ORM 7 reference.
Schema types
In a hand-written contract, @db. attributes become the field type (String @db.VarChar(255) is VarChar(255)), Json must be written Jsonb, @updatedAt is temporal.updatedAt(), cuid() is cuid(2), and implicit many-to-many relations need an explicit join model. DateTime values come back as Temporal.Instant, which Node.js 22 and 24 do not have built in. On my Node.js 24.22.0, node -p "typeof Temporal" printed undefined, so a hand-written contract needs temporal-polyfill.
What is missing in Prisma 8?
Prisma 8 does not yet have several Prisma 7 features. The release status page lists $extends, "filtering inside JSON columns, atomic increment, most nested writes, transaction isolation levels, and the P2002-style error codes." $extends will not return; middleware, custom collections and scopes replace it. If your app relies on these, stay on Prisma 7 for now.
| Prisma 7 feature | In Prisma 8 |
| --- | --- |
| $extends | Will not be added. Use middleware, Collection subclasses or scopes |
| { increment: 1 } | Not available. Use raw SQL or read and write in a transaction |
| JSON path filters | Not available. Jsonb compares as a whole; use raw SQL |
| connectOrCreate, nested update/upsert/delete, set | Not available. Only nested create, connect, disconnect |
| isolationLevel, timeout, nested transactions | Not available |
| P2002 / P2025 error codes | Use error.sqlState (23505 = unique violation) or codes like RUNTIME.NO_ROWS |
| omit, relationLoadStrategy, TypedSQL, read replicas | Not available |
| has / hasSome on String[] | Not available. The field works; filter with raw SQL |
| MySQL, SQL Server, CockroachDB | Not yet. Stay on Prisma 7 |
I replaced an increment with the documented raw SQL builder, and it ran on 8.0.0-rc.18:
import { db } from "./prisma/db.ts";
const post = db.sql.public.Post;
const bump = db.raw.sql`UPDATE "Post" SET views = views + 1 WHERE id = ${id} RETURNING id, views`
.returnsRow({ id: post.columns.id, views: post.columns.views })
.build();
const rows = await db.runtime().query(bump); // [ { id: 1, views: 3 } ]
How do I migrate from Prisma 7 to Prisma 8?
Run both versions side by side on the same database. One command (npx prisma@latest orm init --from-prisma7-schema prisma/schema.prisma) renames Prisma 7 to prisma7, installs Prisma 8, and lets it read your existing schema.prisma. You then sign the database, move routes one at a time, and hand migrations to Prisma 8 only when you choose.
!The five phases of a Prisma 7 to Prisma 8 migration: prepare Prisma 7 as prisma7, add Prisma 8, move routes one at a time, transfer migration ownership with db sign and migration plan, then remove Prisma 7
This is the path from Prisma's official Prisma ORM 7 to 8 guide, and the prisma8-and-7-example repo shows each phase. My test app was a Hono API on Prisma 7.10.1 with @prisma/adapter-pg, PostgreSQL 17.11, Node.js 24.22.0, a Role enum, a DateTime @default(now()), a Json? column and an increment update.
Step 1: Run orm init
npx prisma@latest orm init --from-prisma7-schema prisma/schema.prisma
Write prisma@latest in full, because inside a Prisma 7 project npx prisma still runs version 7. In CI or from a coding agent, the command stops and asks for consent:
CLI.CONSENT_REQUIRED: "Prisma 7 is installed as `prisma`. Keep it as @prisma/prisma7
(binary prisma7) and move `prisma` to Prisma 8, and rename prisma.config.ts to
prisma7.config.ts?" requires explicit consent, and the session is not interactive.
Grant it by passing --confirm app.
Note that it had already added @prisma/orm-postgres to package.json before it stopped. With --confirm app it finished and changed exactly this:
"dependencies": {
"@prisma/adapter-pg": "^7.10.1",
"@prisma/client": "^7.10.1",
+ "@prisma/orm-postgres": "^8.0.0-rc.18",
},
"devDependencies": {
+ "@prisma/cli-engine": "^0.7.0",
+ "@prisma/prisma7": "^7.10.1",
- "prisma": "^7.10.1",
+ "prisma": "^8.0.0-rc.23",
}
It renamed prisma.config.ts to prisma7.config.ts (now importing @prisma/prisma7/config), wrote a new prisma.config.ts, and emitted the client into src/prisma/:
// prisma.config.ts (written by orm init)
import "dotenv/config";
import { definePrismaConfig } from "@prisma/cli-engine";
import { defineConfig as ormConfig, prisma7Schema } from "@prisma/orm-postgres/config";
export default definePrismaConfig({
orm: ormConfig({
contract: prisma7Schema("prisma/schema.prisma"),
output: "src/prisma",
db: { connection: process.env["DATABASE_URL"]! },
}),
});
npx prisma --version now reports 8.0.0-rc.23, and npx prisma7 generate still writes the Prisma 7 client. Update every script and CI step that must keep using Prisma 7 to call prisma7.
Step 2: Sign the database
$ npx prisma db sign
✔ app: signed b3b45c6c5fd8… (no marker before)
✔ Database signed
✔ Advanced ref "db" → b3b45c6c5fd8…
$ npx prisma db verify
✔ Database marker and schema match contract
db sign changes no tables. It adds a prisma_contract.marker table that records which contract hash the database satisfies. Prisma 7 still owns migrations, so after every prisma7 migrate dev or prisma7 migrate deploy, run npx prisma contract emit and npx prisma db sign again.
Step 3: Move one route
// src/routes/users.ts — now on Prisma 8
import { db } from "../prisma/db.ts";
users.get("/", async (c) => {
const result = await db.orm.public.User.include("posts", (posts) =>
posts.orderBy((post) => post.id.asc()),
)
.orderBy((user) => user.id.asc())
.all();
return c.json(result);
});
users.post("/", async (c) => {
const body = await c.req.json<{ email: string; name?: string }>();
try {
return c.json(await db.orm.public.User.create(body), 201);
} catch (error) {
// No P2002 in Prisma 8: check the PostgreSQL SQL state instead
if (error instanceof Error && "sqlState" in error && error.sqlState === "23505") {
return c.json({ error: "email already exists" }, 409);
}
throw error;
}
});
The posts route stayed on Prisma 7, including its increment. A post written through Prisma 7 appeared in the next Prisma 8 read, and a duplicate email returned my 409. tsc --noEmit passed on TypeScript 6.0.3 and, as a bonus, on TypeScript 7 7.0.2.
Step 4: Hand migrations to Prisma 8
When you are ready, convert the Prisma 7 schema into a real contract, point the config at it, sign, then plan a change:
npx prisma contract print --output prisma8/contract.prisma
# set contract: "prisma8/contract.prisma" in prisma.config.ts
npx prisma contract emit
npx prisma db sign
The printed contract produced the same hash as the Prisma 7 schema (unchanged, already signed), so nothing drifted. It mapped my types like this:
// use prisma-8
namespace public {
model User {
id Int @id @default(autoincrement())
email String
name String?
role pg.enum(Role) @default("USER")
createdAt TimestampString(3) @default(now())
posts Post[]
@@index([email], map: "User_email_key", unique: true)
}
native_enum Role {
USER = "USER"
ADMIN = "ADMIN"
}
}
Then I added bio String? and ran the new migration loop:
$ npx prisma contract emit
$ npx prisma migration plan --name add_user_bio
→ Review migrations/app/20261017T1408_baseline and migrations/app/20261017T1409_add_user_bio
$ npx prisma db migrate --advance-ref db
✔ Applied 1 migration(s) (1 operation(s)) across 1 contract space(s)
├─ Add column "bio" to "User"
$ npx prisma db verify
✔ Database marker and schema match contract
The first plan writes a baseline (the schema Prisma 7 built) plus your change. db migrate skips the baseline because the marker already records it. Each migration is a reviewable migration.ts:
override get operations() {
return [
this.addColumn({
schema: "public",
table: "User",
column: col("bio", "text", { codecRef: { codecId: "pg/text@1" } }),
}),
];
}
The Prisma 7 routes kept working after the new column. From here, retire prisma7 migrate from your scripts, move the remaining routes, and finally remove @prisma/prisma7, @prisma/client and @prisma/adapter-pg.
What broke when I ran Prisma 7 and 8 side by side?
Two things the guide doesn't warn about. First, orm init needs --confirm app in any non-interactive shell (CI, Docker, coding agents). Second, createdAt timestamps written by Prisma 8 were 5 hours off. Prisma 7 fills @default(now()) in the client in UTC, but Prisma 8 leaves it to the database, which used my server's local time zone.
The evidence, from the same User table:
id | createdAt written by
1 | 2026-10-17 14:06:44.701 Prisma 7 (UTC)
2 | 2026-10-17 19:08:52.282 Prisma 8 (server time zone Asia/Karachi, UTC+5)
4 | 2026-10-17 14:09:08.795 Prisma 7 (UTC)
Prisma 7 created the column as TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, which is timestamp without time zone. Prisma's own mapping table says @default(now()) in Prisma 8 "is a database default." For a timestamp column, PostgreSQL then writes the time in the session's TimeZone setting, which defaults to the server's. After ALTER DATABASE p8demo SET timezone TO 'UTC', Prisma 8 wrote 14:09:20 at 14:09:20 UTC.
Many managed PostgreSQL services default to UTC, so you may never see this. Check before mixing writers:
SHOW timezone; -- must be UTC (or Etc/UTC) while Prisma 7 and 8 both write
Also note the data type change: read through prisma7Schema(...), DateTime comes back as a string such as "2026-10-17 14:06:44.701", not a Date. My JSON responses changed format between the two routes (2026-10-17T14:06:44.701Z from Prisma 7), so API clients that parse dates should be tested.
Should I upgrade to Prisma 8 now?
Not for production apps yet. Pin Prisma 7 today, because that protects you from the latest tag change, and plan the move after GA. Start with Prisma 8 now only for new PostgreSQL projects that don't need the missing features, or to trial it on one route of an existing app with the side-by-side setup.
!Decision flow for Prisma 8: stay on Prisma 7 for MySQL, SQL Server or CockroachDB, or if you use $extends, nested updates, increment, JSON filters or P2002 codes; otherwise trial Prisma 8 side by side or start new PostgreSQL projects on it
| Your situation | Recommendation |
| --- | --- |
| Prisma 6 | Upgrade to Prisma 7 before November 19, 2026 |
| Prisma 7 on MySQL, SQL Server or CockroachDB | Stay on 7; Prisma 8 doesn't support them yet |
| Prisma 7 using $extends, nested updates, JSON filters or P2002 | Stay on 7 until those have replacements you accept |
| Prisma 7 on PostgreSQL, simple CRUD | Pin 7 now; trial 8 on one route after GA |
| New PostgreSQL project | Prisma 8 is reasonable; expect small API edits until GA |
| Using Accelerate | Switch connections before December 1, 2026 regardless |
What happens to Prisma Accelerate?
Prisma retires Accelerate on December 1, 2026, according to its October 2 changelog. If your connection string starts with prisma+postgres://accelerate.prisma-data.net, switch to a pooled connection or the serverless driver before then. Accelerate's query caching has no replacement, so remove cacheStrategy from your queries first.
The same changelog sets a second deadline: Prisma Postgres Early Access databases, the ones still on PostgreSQL 16, "are deleted on November 1, 2026 at 00:00 UTC." Move each one to a new database before then. Both deadlines apply whether you stay on Prisma 7 or move to 8.
Prisma 8 upgrade checklist
Pin Prisma 7 first, then handle the deadlines, then migrate on your own schedule. These steps follow the official guide plus what I hit in testing.
1. Pin prisma and @prisma/client to ^7 and replace every unpinned npx prisma in CI and Dockerfiles with npx prisma@7 or a lockfile install.
2. Leave Accelerate before December 1, 2026, and move Early Access Prisma Postgres databases before November 1.
3. Check requirements: Node.js 22.18+, 24.11+ or 26+, TypeScript 5.9+ with strict, PostgreSQL.
4. Audit for missing features: $extends, increment, nested updates, JSON filters, isolation levels, P2002 handling.
5. Check the database time zone with SHOW timezone; and set it to UTC if Prisma 7 and 8 will both write.
6. Run npx prisma@latest orm init --from-prisma7-schema prisma/schema.prisma (add --confirm app in CI).
7. Run npx prisma db sign, then move one low-risk route to db.orm.
8. After each prisma7 migration, run prisma contract emit and prisma db sign.
9. Transfer migrations with contract print, db sign, migration plan, db migrate --advance-ref db.
10. Remove Prisma 7 when nothing imports @prisma/client.
Common Prisma 8 mistakes
The most common mistakes are letting prisma@latest slip into a Prisma 7 build, running Prisma 8's db init or db update against a database Prisma 7 already manages, forgetting to re-sign after a Prisma 7 migration, and assuming DateTime and error handling behave the same in both clients.
| Mistake | Symptom | Fix |
| --- | --- | --- |
| Unpinned prisma in CI | No command registered for generate | Pin ^7 or use npx prisma@7 |
| orm init in CI without consent | CLI.CONSENT_REQUIRED | Add --confirm app |
| db init / db update on a Prisma 7 database | Skips the signed handoff; the guide says to run neither | db sign, then the phase 4 handoff |
| Not re-signing after prisma7 migrate | db verify reports a contract mismatch | contract emit, then db sign |
| Catching P2002 in moved routes | Unique violations crash as 500s | Check error.sqlState === "23505" |
| Server time zone not UTC | Prisma 8 timestamps offset by hours | ALTER DATABASE ... SET timezone TO 'UTC' |
| Expecting Date objects | Strings or Temporal.Instant instead | Convert at the API boundary |
| Hand-written contract on Node.js 24 | Temporal is undefined | import "temporal-polyfill/full/global" |
Related: I benchmarked Prisma 8 RC against Prisma 7 and Drizzle in Drizzle vs Prisma in 2026: Prisma 8 RC had the slowest bundled cold start (about 370 ms). If you use Better Auth, note that Better Auth 1.7 supports Prisma 5 to 7 but not Prisma 8 yet; see my Better Auth with Next.js 16 setup.
Related: Prisma's @default(uuid(7)) generates IDs in the client and sets no database default. On PostgreSQL 18 you can use dbgenerated("uuidv7()") instead; see my UUIDv7 in PostgreSQL 18 benchmark.
Key takeaways
- Prisma 8 is a release candidate (prisma 8.0.0-rc.23, @prisma/orm-postgres 8.0.0-rc.18 on October 17, 2026) with GA expected in October 2026, but npm's latest tag already installs it.
- Pin prisma and @prisma/client to ^7 today; the Prisma 8 CLI has no generate, migrate or db push.
- Prisma 8 replaces schema.prisma with a contract, prisma generate with prisma contract emit, and @prisma/client with @prisma/orm-postgres and chained queries.
- $extends, increment, most nested writes, JSON filters, isolation levels and P2002 codes are missing, and only PostgreSQL is fully supported.
- orm init --from-prisma7-schema runs Prisma 7 and 8 side by side on one database; it needs --confirm app outside an interactive terminal.
- Check SHOW timezone before mixing writers: Prisma 8 leaves now() to the database, which skewed my timestamps by 5 hours.
- Prisma 7 is supported for 18 months after Prisma 8 GA, Prisma 6 security patches end November 19, 2026, and Accelerate retires December 1, 2026.
---
Originally published on fabwaseem.com.
Mentions
Neon serverless Postgres: architecture, pricing, use cases, and tradeoffs Many conventional PostgreSQL deployments keep compute running continuously and pair it with provisioned storage. Isolated test environments often require snapshots or full copies, although the exact architecture varies by provider. Continuously running compute can be a poor fit for intermittent traffic and temporary preview environments. Neon separates stateless Postgres compute from a distributed storage layer. This separation enables scale-to-zero compute, rapid database branching, and usage-based pricing. The decision to adopt Neon depends on whether the compute lifecycle, copy-on-write branching, and proxy-routed connection model fit your application better than conventional managed Postgres or a broader backend platform. TL;DR - Neon fits teams that need fast database branching, preview environments, support for intermittent workloads, or AI/Postgres prototyping. - Neon separates stateless compute from durable storage, enabling scale-to-zero and copy-on-write branches. - Validate cold starts, SNI routing, PgBouncer transaction pooling, ORM behavior, and branch governance before production use. - Compare alternatives when a measured requirement is decisive: AWS-native operations, full infrastructure control, local NVMe with the required replication and durability settings, or a dedicated analytical path after OLTP and reporting contention appears. What is Neon serverless Postgres? Neon is a fully managed, serverless PostgreSQL database built on a custom storage architecture. Its engineering documentation now calls the database Lakebase Postgres. It separates Postgres compute from distributed storage built around write-ahead logs (WAL), safekeepers, pageservers, and durable object storage. The Neon backend reached general availability in September 2026 with Object Storage, Functions, Managed Better Auth, and AI Gateway alongside the database. Teams can use those services or external alternatives for adjacent application requirements. The PostgreSQL compute primarily serves transactional workloads. Neon manages infrastructure, compute lifecycle, storage durability, and branching. Customers remain responsible for schema design, indexing, query tuning, access control, connection routing, retries, branch data governance, and cost controls. The selected plan determines available controls. Free requires suspension after five idle minutes; Launch can disable that timeout; Scale can configure it. Scale also adds IP allowlisting and private networking. How does Neon work? Neon resource hierarchy and connection paths Neon environments are structured around these configuration objects and connection paths. - Project: The top-level container for a database environment, holding all associated branches, computes, databases, roles, and settings. - Branch: An isolated, copy-on-write timeline of the database state. You can create branches from other branches or from a specific point in time in the storage history. - Database: A standard Postgres database residing inside a branch. - Role: A Postgres role for authentication, authorization, and connection management. - Compute: A Postgres instance attached to a branch. The compute executes queries, manages memory caches, and handles sessions, but holds no permanent durable state. - Endpoint: The connection target for a compute. Endpoints are available as direct or pooled connections. - Connection proxy and TLS SNI routing: Neon routes PostgreSQL connections through a proxy that identifies the correct tenant compute from the TLS Server Name Indication (SNI). Clients must support SNI. Legacy libpq builds, older Django configurations, and some desktop tools require client upgrades or explicit endpoint ID connection options to prevent "The endpoint ID is not specified" errors. - Direct endpoint: The standard PostgreSQL port for administrative operations, schema migrations, pg_dump, long-lived sessions, and workflows requiring session-level Postgres features. - Pooled endpoint: A PgBouncer-backed connection path using transaction pooling, designed for applications with many short-lived client connections. - HTTP/WebSocket serverless driver paths: Custom driver connections for JavaScript, edge, and serverless runtimes where persistent TCP connections are restricted or inefficient. - Read replica: A read-only compute endpoint attached to a branch to isolate read traffic. Core Neon architecture components and boundaries The Neon architecture divides responsibilities between execution and durable state. The Postgres compute node handles query execution, in-memory caching, sessions, and supported extensions. Safekeepers receive the WAL stream from the compute node and ensure durable acceptance. Pageservers serve database pages to the compute node on demand and reconstruct page state from the underlying object storage history. Object storage retains the long-term immutable history required by the storage layer. Compute nodes maintain the cache and execution responsibility, but all durable state belongs to the networked storage layer. What happens during a Neon transaction? During a write transaction, the Postgres compute executes the query and streams the resulting WAL to the safekeepers. Commit acknowledgment depends on the storage and WAL durability path, not on a local filesystem fsync. Reads check Postgres shared buffers, then Neon's Local File Cache where enabled. A miss requires a network request to the pageserver. Fixed computes of 18 CU or more disable the file cache and allocate more memory to shared buffers. When you create a branch, the system points a new timeline to an existing point in the storage history. Copy-on-write avoids an immediate full copy. Branch storage charges depend on divergence and retention; even an unchanged child branch can incur root-branch storage charges once it falls outside the history window. What Neon's separated compute and storage design enables and constrains Neon's architecture affects compute lifecycle, branching, storage latency, and connection behavior: - Separated durable storage allows computes to suspend, resize, or restart without moving a physical database volume, so computes can scale to zero. - Copy-on-write history allows rapid branch creation, enabling CI/CD pipelines and preview environments to use production-like state quickly. - The networked storage path means cache misses require a network request to the pageserver. Teams must test cold-cache latency and disk-heavy queries carefully. - Proxy-routed connections demand SNI-capable clients or explicit endpoint identifiers, requiring connection testing for older ORMs, tools, and CI images. - PgBouncer transaction pooling does not preserve arbitrary session state or SQL-level PREPARE across transactions; protocol-level prepared statements are supported. What are Neon's key capabilities? Database branching for preview environments Neon creates isolated, copy-on-write branches for development, staging, and migration rehearsals. Branching fits pull request environments, destructive schema migration testing, and reproducing production bugs against accurate data. One team using Neon reported that separate development, staging, and test branches reduced friction between developers. An April 2026 Hacker News commenter also described returning to Neon for branching after trying another provider. The primary constraints involve data governance and cost. Branches containing sensitive production data require strict masking rules or synthetic data substitution. Over time, abandoned branches and retained history increase storage, demanding automated retention policies and cleanup. Scale-to-zero compute and autoscaling Neon supports fixed-size and autoscaling compute. Eligible idle computes can suspend while durable data remains in storage, stopping compute charges. Scale-to-zero fits intermittent applications, internal tools, and preview databases with extended idle windows. The primary constraint is wake-up latency. Resuming a suspended compute takes time, which can trigger client-side connection timeouts. In a February 2025 account of a personal Django project on Neon Free, the author reported a 12-second first request, an improvement after changing providers, and a separate N+1 fix for the admin page. That request time did not isolate database wake-up latency. Measure the suspended-to-first-query path on the selected plan. Scale-to-zero controls apply to computes up to 16 CU. Free has a mandatory five-minute idle timeout. Launch retains five minutes but can disable suspension; Scale supports settings from one minute to always on. Larger fixed computes remain active. Connection pooling, PgBouncer, and serverless connection paths Neon provides multiple connection strategies: direct endpoints, pooled endpoints, and serverless HTTP/WebSocket drivers. Pooled endpoints use PgBouncer in transaction pooling mode to handle high-fanout serverless functions and web applications with frequent, short-lived requests. SQL-level PREPARE/EXECUTE and other session-bound state are not portable across transactions, while Neon's PgBouncer path supports protocol-level prepared statements. Use a direct endpoint for stable-session operations and validate the deployed ORM version. Runtime placement also matters. In an Expo discussion, a developer described using Neon across several projects through Expo's server-side API routes. That setup keeps the database connection in server code rather than the mobile client. Read replicas and read-only compute endpoints Neon offers read-only compute endpoints for routing analytical or heavy read traffic away from the primary write compute. Users still create read-replica compute endpoints, but those computes attach to shared storage without copying the full dataset. WAL reaches replicas asynchronously, so read-after-write behavior must be tested. Read replicas fit read-heavy dashboards, API query endpoints, and reporting tasks. Teams must validate read-after-write expectations, replica freshness, cache warm-up behavior, and the cost impact of running additional active compute hours. What is Neon used for? Creating branch-based preview environments Separate branch computes isolate query execution for pull requests and migration testing without copying the full database. CI/CD automation must create, tag, scrub, and delete those environments reliably; production-derived data still requires masking and access controls. Running intermittent, bursty, and serverless applications Neon's autoscaling and scale-to-zero mechanisms fit applications with cyclical usage or long idle windows. The cost benefit depends on actual suspension time, and the application must tolerate resume latency and connection retries. AI and RAG prototyping with Postgres and pgvector AI applications often need disposable environments for experiments with embeddings, retrieval-augmented generation (RAG) pipelines, and vector indexing. Neon supports extensions such as pgvector, while branching isolates experiments safely. Vector workloads demand significant memory and cache resources. Teams must test representative embedding volumes, index choices, and query latency under realistic concurrency. Provisioning development and test databases quickly Disposable databases can reduce the need to manage local Postgres containers or share a staging cluster. Neon's projects, branches, and API-driven endpoints provide repeatable provisioning workflows. A Next.js developer who had used both Neon and Supabase preferred Neon with Drizzle for keeping schema definitions in the codebase and iterating in TypeScript. Drizzle also works with Supabase. Before scaling this pattern, standardize environment naming, credential rotation, developer permissions, and cleanup automation. What should you know before using Neon in production? Reliability and failure handling in Neon Neon's separated compute and storage model shifts how failures behave compared to single-host deployments. Compute lifecycle events, storage-path network requests, and point-in-time recovery operate differently than traditional local-disk failovers. | Production concern | Neon behavior to account for | Application responsibility | What to test | | :---- | :---- | :---- | :---- | | Compute restart, manual resize, or resume | Restarts and manual size or autoscaling-bound changes disconnect sessions. Automatic autoscaling preserves them. Resume can delay new connections. | Reconnect gracefully, retry safe operations, and enforce write idempotency. | ORM pool recovery, retry limits, cold starts, and manual configuration changes. | | Transaction interruption | A lost connection can leave the client uncertain whether a transaction committed. | Handle commit uncertainty and implement duplicate-prevention logic. | Idempotency keys and transaction retry boundaries. | | Storage-path network latency | Cache misses require networked pageserver requests, surfacing latency during heavy un-cached reads. | Avoid assuming local-disk latency guarantees for cache misses. | Cold-cache read latency, heavy sequential scans, and block I/O behavior. | | Point-in-time recovery (PITR) | Instant restore restores a root branch in place, affecting every database on it. Connection details stay unchanged; the previous state becomes a backup branch. Existing connections are interrupted. | Select the recovery point, verify restored data, and reconnect clients. | Restore rehearsals, branch-wide impact, data verification, and connection recovery. | In two May 2025 incidents, Neon reported 5.5 hours of impaired database creation and startup in AWS us-east-1; running databases were unaffected. Neon addressed IP allocation and capacity constraints. The incidents illustrate why startup availability matters separately from running-query availability. Review regional incident history and decide whether production computes should suspend. Security, permissions, and branch data governance Neon encrypts data in transit and at rest. Among its self-service plans, Scale includes IP allowlisting and private networking; Launch does not. Private networking uses AWS PrivateLink and requires the application and database to be in the same AWS region. PostgreSQL roles, schema privileges, and row-level security operate natively. Configuring them remains the customer's responsibility. Branch governance requires rules for who can copy production data and how it is masked. In an April 2026 engineering account, a team pulled back from production-derived pull-request branches because masking rules could miss new columns or JSON fields; it preferred synthetic data until masking coverage could be enforced. Neon's anonymization feature applies static masking rules to specified tables and columns. Teams still own rule coverage, credentials, permissions, and branch cleanup. Session semantics and ORM integration Session advisory locks, LISTEN/NOTIFY, temporary tables that must survive across transactions, and other stable-session features belong on a direct endpoint. For Prisma, current Neon guidance specifies a pooled application URL and a direct URL for CLI schema operations, including prisma migrate and prisma db push. A suspended compute can exceed a client's connection timeout and surface an error such as Prisma P1001. In 2025 replies to a Prisma discussion, increasing connect_timeout helped some users but not others. Measure resume latency against the configured timeout, then test bounded retries only for operations that are safe to retry. Monitoring, maintenance, and scale-to-zero blockers The Neon console provides visibility into CPU, memory, storage, connections, and basic Postgres telemetry. Teams remain responsible for query tuning, index optimization, and slow-query analysis using standard tools like pg_stat_statements. Repeated connection requests and queries can prevent scale-to-zero. An idle open connection alone does not keep compute active, but pool validation queries, scheduled jobs, and database health checks can. One SaaS founder reported a \$157 monthly bill and attributed unwanted activity to workflow automation, an AI editor's database integration, and application polling. Audit those clients and queries alongside the autosuspend setting. Adoption requirements and exit constraints Adopting Neon requires updating database connection strategies to handle direct, pooled, and serverless driver endpoints appropriately. Migration involves standard dump and restore processes, logical replication, or CSV imports, depending on database size and downtime tolerance. Postgres schema and data remain portable, while Neon-specific integrations can require rework. In a February 2026 Replit development-database migration, the author reported that data, row-level security policies, and functions survived and TCP connections worked. Code using Neon's HTTP serverless driver needed a replacement. Branching automation and compute-lifecycle assumptions also need review before an exit. How much does Neon cost? Pricing model and cost drivers As of October 2026, Neon's self-service plans bill by resource consumption with plan-specific allowances and controls. Pricing changes since August 2025 mean older invoices reflect different rates or minimums; use the current pricing page for estimates. | Plan area | What it includes | Why it matters | | :---- | :---- | :---- | | Plan | Self-service plans use usage-based pricing, while included allowances and features vary by plan. | Determines feature access, support, and included usage. | | Compute | Compute Unit (CU) hour pricing, driven by actual compute size and active time. | Determines the compute portion of the bill for active and always-on workloads. | | Storage and history | GB-month pricing for stored data, branch deltas, and retained restore history. | Creates ongoing charges even when compute is suspended. | | Additional branches and data transfer | Included allowances and any additional charges depend on the current plan. | Matters for branch-heavy workflows, exports, and cross-cloud traffic. | | Limits and security | Branch allowances, compute sizes, monitoring retention, IP allowlisting, and private networking vary by plan. | Determines whether the required production controls are available. | Compute charges follow actual CU size multiplied by active time. The autoscaling maximum caps possible usage but is not billed capacity; background activity can prevent idle suspension and increase CU-hours. Paid-plan allowances also differ from Free. In May 2026, one Launch customer reported that Free's compute allowance did not carry over. Check the selected plan's included usage before extrapolating from a Free project. Branching is lightweight at creation, but divergent writes and active branch computes incur ongoing fees. Cost examples for bursty and sustained workloads Bursty preview-environment scenario: For short-lived pull-request branches, calculate the cost from active compute time, compute size, storage, restore history, branch usage, and data transfer. A branch that is active only during testing and then suspends may consume fewer CU-hours than an equivalent always-on staging instance. Sustained OLTP scenario: A continuously active compute accrues CU-hours without idle savings. Compare its monthly compute and storage costs against a fixed-size managed Postgres instance. In August 2025, OpenSecret cited rising usage-based costs among its reasons for moving four databases supporting an always-on application to PlanetScale's fixed-price service. For one smaller deployment, a December 2025 account from a user with two active projects reported a \$38 monthly bill, considered the pricing reasonable, and cautioned that egress could add up. What makes Neon costs rise? Pool validation queries, pg_cron jobs, or database health checks increase costs when they keep computes active. Leaving scale-to-zero disabled for development endpoints, allowing branch sprawl without cleanup policies, and retaining extensive history windows on high-write databases inflate storage and compute bills. Large data exports, analytics pipelines, or cross-region application traffic will also drive up network egress charges. What are Neon's limitations and tradeoffs? Networked storage can increase cold-cache latency Reads that miss shared buffers and the Local File Cache, where enabled, require a network request to the pageserver. Fixed computes of 18 CU or more rely on larger shared buffers instead of the file cache. End-to-end latency depends on the working set, compute size, query shape, and compared storage system. Teams should first test cold-cache latency and disk-heavy queries against workload targets. Consider a configuration or architecture change only when those measurements show that the current approach cannot meet those targets. Serverless lifecycle changes connection and retry assumptions Applications must handle resume latency, interrupted sessions, and bounded reconnects. Keeping compute active removes suspension-related wake-up delays and idle savings; it does not remove other connection failure modes. Troubleshooting accounts identify several possible causes: connections accumulating during NestJS hot reload in May 2026, network problems addressed with VPN or DNS changes in a Prisma thread, and Node.js address selection in August 2026. Diagnose the connection path and application behavior before attributing an error to Neon. PgBouncer transaction pooling changes session semantics Neon's built-in pooling multiplexes traffic efficiently but does not preserve arbitrary session state across transactions. Applications can route session-dependent operations to the direct endpoint instead of abandoning those features entirely. Proxy routing and SNI require compatible clients The ingress routing architecture requires TLS SNI. Legacy libpq installations, older ORMs, CI pipeline containers, and some database GUI tools fail to connect without explicit endpoint parameters. Validate all operational scripts and runtime environments before migration. Heavy analytics and always-on workloads may reduce Neon's fit Heavy aggregations and analytical scans executed on the same PostgreSQL compute compete with transactions for resources. Neon's read replicas isolate query execution on separate computes; moving reporting traffic requires application routing. Continuous, always-on production traffic nullifies scale-to-zero savings. When measurements show that reporting load causes transactional requests to miss their latency target, teams should evaluate a dedicated analytical system. Managed service boundaries limit low-level PostgreSQL control Neon does not provide arbitrary operating system access, custom compiled extensions, deep kernel tuning, or direct filesystem control. Applications requiring niche OS dependencies, highly specialized replication setups, or custom infrastructure architectures should evaluate self-managed PostgreSQL. How does Neon compare with Supabase, Aurora, self-managed PostgreSQL, and ClickHouse Managed Postgres? Compare alternative deployment models based on which specific backend, AWS-native, infrastructure-control, or I/O requirement outranks serverless branching. | Decision baseline | Prefer it when | What changes relative to Neon | Decision trigger | | :---- | :---- | :---- | :---- | | Supabase | The team wants Supabase's Postgres, Auth, Storage, Realtime, and Edge Functions workflows. | Both are backend platforms: Supabase centers its established application-service bundle around each Postgres project, while the Neon backend centers its branching Postgres model and adds Object Storage, Functions, Managed Better Auth, and AI Gateway. | Choose Supabase when its Postgres, Auth, Storage, Realtime, and Edge Functions workflows are decisive; choose Neon when branchable database and backend primitives plus Neon's compute lifecycle fit the application better. | | Amazon RDS or Aurora | The organization standardizes on AWS operations, procurement, networking, governance, and compliance workflows. | AWS-native integration, IAM alignment, and established VPC patterns dictate the operational model. | Choose RDS/Aurora when AWS alignment, existing commitments, or enterprise operational standardization outweigh database branching. | | Self-managed PostgreSQL | The team requires full control over the OS, specialized extensions, storage layout, custom backups, replication, or specialized tuning. | Operational ownership shifts to the customer, encompassing HA, patching, monitoring, security, and failover mechanics. | Choose self-managed Postgres when total infrastructure control, legal compliance, or extension requirements outweigh managed-service convenience. | | ClickHouse Managed Postgres | Sustained, performance-critical OLTP calls for always-on compute and local NVMe, or a separate ClickHouse analytical service. | Local NVMe-backed Postgres offers no standby, one asynchronous standby, or two synchronous standbys. Replication to a separately provisioned ClickHouse service is asynchronous, so the analytical copy is eventually consistent. | Evaluate local NVMe with the standby configuration the application requires. Choose this model when measured transactional performance or the separate analytics path matters more than serverless branching. | How should you evaluate Neon for your workload? 1. Define pass/fail criteria: Set targets for suspended and warm latency, connection handling, data governance, and monthly costs. 2. Provision a representative environment: Import schema and data, configure runtime and migration roles, and create a test branch. 3. Select connection paths: Use direct endpoints for session-dependent tools, pooled endpoints for short application transactions, and supported HTTP/WebSocket drivers for edge runtimes. Test legacy clients for SNI compatibility. 4. Validate ORM and migration tooling: Follow Neon's Prisma guidance: pooled connections for application queries, direct connections for prisma migrate and prisma db push. Test the deployed versions. 5. Test lifecycle and recovery: Compare suspended and warm query paths, bound safe retries, and rehearse restores. Confirm the plan supports the required suspension settings. 6. Implement branch governance: Automate creation, masking, retention, and deletion. Test replica freshness and cache warm-up if using read replicas. 7. Establish the escalation owner: Confirm support responsibilities across providers. In a July 2025 Azure-hosted Neon account, the author credited Neon's support with resolving the issue after coordination with Azure complicated troubleshooting. 8. Model costs and decide: Include compute size and active time, storage, history, branches, and egress. If continuous activity removes idle savings, re-model the economics against fixed-size managed options. Evaluate alternatives when measured latency, tooling, governance, or cost requirements remain unmet. Conclusion: Is Neon right for your team? Neon fits PostgreSQL teams that need branch-based development workflows, fast preview environments, elastic compute, and idle-time savings. It supports AI prototyping and pull-request automation when rapid environment provisioning and an idle-time compute model are priorities. The decision changes when your workload demands predictable warm performance, session-heavy Postgres semantics, a locally attached storage architecture, extensive OS-level customization, or heavy analytical capabilities that disrupt OLTP latency. Proceed if measured connection behavior, data governance, and pricing fit your requirements. Disabling scale-to-zero does not by itself disqualify Neon because fixed-size and autoscaling always-active computes remain available. For sustained, performance-critical OLTP, compare ClickHouse Managed Postgres using the standby configuration the application requires and representative queries. Evaluate its separately provisioned ClickHouse analytics path when reporting isolation is decisive. Frequently asked questions about Neon What workloads is Neon best for? Neon fits preview environments, branch-based development, intermittent applications, serverless workloads, and AI/Postgres prototypes when fast provisioning and scale-to-zero reduce cost or operational friction. Is Neon suitable for production? Yes, Neon supports production workloads. Production deployments require appropriate compute sizing, connection routing, retry logic, branch data governance, and cost modeling. Configure autoscaling limits if autoscaling is enabled. Does Neon scale to zero? Yes, eligible computes up to 16 CU can suspend, stopping compute charges while storage and other applicable charges continue. Free requires a five-minute idle timeout; Launch can disable it; Scale can configure one minute to always on. Repeated connection requests and background queries can prevent suspension; an idle open connection alone does not. Should I use Neon's direct or pooled connection string? Use the direct connection for migrations, admin tools, dumps, and session-dependent workflows. Use the pooled PgBouncer connection for high-concurrency applications with short transactions after validating transaction-pooling compatibility. Does Neon work well with Prisma? Yes. Neon's current Prisma guide uses a pooled URL for application queries and a direct URL for prisma migrate and prisma db push. Test suspended-compute wake-up latency against Prisma's connection timeout, and add bounded retries only for operations that are safe to retry. Is Neon suitable for analytics workloads? Neon supports operational reporting, and read replicas can move analytical queries onto separate compute. Heavy scans on the primary can compete with transactions. Evaluate a dedicated analytical database when query latency, concurrency, freshness, or total compute cost remains unsuitable after assessing Neon's read-replica approach. How can I keep Neon costs under control? Control costs by deleting unused branches, limiting retained history, auditing background jobs that prevent suspension, setting appropriate autoscaling limits, and comparing always-on compute costs against fixed managed Postgres options. Is Neon branching safe for production data? Branching is useful, but branches created from production data require governance. Use masking, access controls, retention policies, and automated cleanup to prevent sensitive data exposure and branch sprawl. When should I not use Neon? Consider alternatives when a tested requirement cannot be met, such as unsupported OS-level control, session-bound behavior that cannot use direct endpoints, or cold-cache and analytical latency outside the workload's target. Continuous traffic alone is not a disqualifier; it removes scale-to-zero savings but can still use autoscaling. How is Neon different from Aurora Serverless? Choose Neon when fast branching, preview databases, and scale-to-zero Postgres are decisive for your workflow. Choose Aurora when AWS-native networking, IAM, procurement, or enterprise governance is decisive.
Prisma 8 vs Prisma 7: Should You Upgrade? A Tested Migration Guide Heads up if any of your projects, CI jobs or Dockerfiles run npm install prisma without a version pin: since August 2026 that installs a Prisma 8 release candidate. I migrated a Prisma 7 app on PostgreSQL 17 side by side, and this is what I found. Prisma 8 is a rewrite of Prisma ORM, not a version bump. The schema becomes a contract, prisma generate becomes prisma contract emit, @prisma/client is replaced by @prisma/orm-postgres, and queries are chained (db.orm.public.User.where(...).all()). It is still a release candidate, but since August 2026 npm install prisma installs it. That last fact is the urgent part. Any Prisma 7 project, CI job or Dockerfile that installs prisma without a version now gets a CLI with no generate, migrate or db push. I upgraded a real Prisma 7 app on PostgreSQL 17 with the official side-by-side path, and this guide gives the commands, the output, two gotchas the docs don't spell out, and a clear answer on whether to move now. Facts are cited to the Prisma ORM release status page. What is Prisma 8? Prisma 8 (Prisma ORM 8) is the next major version of Prisma ORM, a typed data layer for TypeScript. You describe models in a contract file, prisma contract emit writes contract.json and contract.d.ts, and you query through a db client from @prisma/orm-postgres. There is no generated PrismaClient, and migrations are TypeScript files you can review. Key facts on October 17, 2026: | | Prisma ORM 7 | Prisma ORM 8 | | --- | --- | --- | | npm tag | prisma@prev (7.10.1) | prisma@latest (8.0.0-rc.23) | | Status | Stable, supported | Release candidate, GA "expected in October 2026" | | Runtime package | @prisma/client + a driver adapter | @prisma/orm-postgres (8.0.0-rc.18) | | Schema file | schema.prisma | contract.prisma (first line // use prisma-8) | | Codegen | prisma generate | prisma contract emit | | Queries | prisma.user.findMany({ where }) | db.orm.public.User.where(...).all() | | Migrations | migrate dev / migrate deploy (SQL) | migration plan / db migrate (TypeScript) | | Databases | PostgreSQL, MySQL, SQL Server, SQLite, MongoDB, CockroachDB | PostgreSQL; MongoDB early access; SQLite experimental | | Node.js | 20.19+, 22.12+ or 24+ | 22.18+, 24.11+ or 26+ | | TypeScript | 5.4+ | 5.9+ | The CLI and the library are versioned separately, so prisma 8.0.0-rc.23 and @prisma/orm-postgres 8.0.0-rc.18 are a matching pair. Prisma says "any two latest versions work together." Is Prisma 8 stable? When is the release date? No, not yet. Prisma 8 is a release candidate, and Prisma's release status page says general availability "is expected in October 2026." On October 17, 2026 the newest builds were prisma 8.0.0-rc.23 (published October 15) and @prisma/orm-postgres 8.0.0-rc.18 (October 14). Prisma warns that "some details of the API may still change." Two support dates follow from the release: - Prisma ORM 7 keeps receiving bug fixes and security updates "for 18 months from the day Prisma ORM 8 reaches general availability." - Prisma ORM 6 receives security patches only until November 19, 2026. So there is no rush to leave Prisma 7, but Prisma 6 projects should move to 7 now. Why does npm install prisma install Prisma 8? Because Prisma moved the npm latest tag to Prisma 8 while it is still an RC. Prisma's August 28 changelog says the release "makes Prisma 8 available through prisma@latest." Prisma 7 is now prisma@prev. A Prisma 7 project that installs prisma without a version range gets a CLI that cannot read its workflow. I ran the old commands with the Prisma 8 CLI in a Prisma 7 project: $ npx prisma generate ✘ [CLI.UNKNOWN_COMMAND] No command registered for `generate` $ npx prisma migrate deploy ✘ [CLI.UNKNOWN_COMMAND] No command registered for `migrate`, did you mean `migration`? $ npx prisma db push ✘ [CLI.UNKNOWN_COMMAND] No command registered for `push`, did you mean `update`? Do this today, even if you never upgrade: pin both packages, then grep your CI, Dockerfiles and scripts for npx prisma and prisma@latest. { "devDependencies": { "prisma": "^7" }, "dependencies": { "@prisma/client": "^7" } } Anywhere a command runs without a lockfile, write npx prisma@7 migrate deploy instead of npx prisma migrate deploy. If you build images with a multi-stage Dockerfile like the one in my Next.js Dockerfile guide, the npm ci step respects the lockfile; a separate npx prisma ... line in a later stage does not. What changed in Prisma 8? Almost everything you type. The schema is a contract, codegen is contract emit, the client is built in src/prisma/db.ts, queries are chained, migrations are TypeScript packages tracked by a hash marker in the database, and several Prisma 7 features ($extends, nested updates, increment, JSON filters, P2002 codes) are missing. Your database tables and data do not change. Commands | Prisma 7 | Prisma 8 | | --- | --- | | prisma generate | prisma contract emit | | prisma migrate dev | prisma db update, or prisma migration plan + prisma db migrate | | prisma migrate deploy | prisma db migrate | | prisma db push | prisma db init (empty database), then prisma db update | | prisma db pull | prisma contract infer | | prisma format | prisma contract format | | prisma migrate reset, prisma db seed, prisma studio | None in the Prisma 8 CLI | Queries | Prisma 7 | Prisma 8 | | --- | --- | | prisma.user.findMany({ where: { active: true } }) | db.orm.public.User.where({ active: true }).all() | | findUnique / findFirst | .where(...).first() (returns null) | | select: { id: true } | .select("id") | | include: { posts: true } | .include("posts") | | orderBy: { id: "asc" } | .orderBy((u) => u.id.asc()) | | take / skip | .limit(n) / .offset(n) | | create({ data: {...} }) | .create({...}) (no data wrapper) | | contains: "ali" / mode: "insensitive" | .like("%ali%") / .ilike("%ali%") | | $transaction(async (tx) => ...) | db.transaction(async (tx) => ...) with tx.orm | | $disconnect() | db.close() | public is the PostgreSQL schema the table lives in. The full mapping is in Prisma's Coming from Prisma ORM 7 reference. Schema types In a hand-written contract, @db. attributes become the field type (String @db.VarChar(255) is VarChar(255)), Json must be written Jsonb, @updatedAt is temporal.updatedAt(), cuid() is cuid(2), and implicit many-to-many relations need an explicit join model. DateTime values come back as Temporal.Instant, which Node.js 22 and 24 do not have built in. On my Node.js 24.22.0, node -p "typeof Temporal" printed undefined, so a hand-written contract needs temporal-polyfill. What is missing in Prisma 8? Prisma 8 does not yet have several Prisma 7 features. The release status page lists $extends, "filtering inside JSON columns, atomic increment, most nested writes, transaction isolation levels, and the P2002-style error codes." $extends will not return; middleware, custom collections and scopes replace it. If your app relies on these, stay on Prisma 7 for now. | Prisma 7 feature | In Prisma 8 | | --- | --- | | $extends | Will not be added. Use middleware, Collection subclasses or scopes | | { increment: 1 } | Not available. Use raw SQL or read and write in a transaction | | JSON path filters | Not available. Jsonb compares as a whole; use raw SQL | | connectOrCreate, nested update/upsert/delete, set | Not available. Only nested create, connect, disconnect | | isolationLevel, timeout, nested transactions | Not available | | P2002 / P2025 error codes | Use error.sqlState (23505 = unique violation) or codes like RUNTIME.NO_ROWS | | omit, relationLoadStrategy, TypedSQL, read replicas | Not available | | has / hasSome on String[] | Not available. The field works; filter with raw SQL | | MySQL, SQL Server, CockroachDB | Not yet. Stay on Prisma 7 | I replaced an increment with the documented raw SQL builder, and it ran on 8.0.0-rc.18: import { db } from "./prisma/db.ts"; const post = db.sql.public.Post; const bump = db.raw.sql`UPDATE "Post" SET views = views + 1 WHERE id = ${id} RETURNING id, views` .returnsRow({ id: post.columns.id, views: post.columns.views }) .build(); const rows = await db.runtime().query(bump); // [ { id: 1, views: 3 } ] How do I migrate from Prisma 7 to Prisma 8? Run both versions side by side on the same database. One command (npx prisma@latest orm init --from-prisma7-schema prisma/schema.prisma) renames Prisma 7 to prisma7, installs Prisma 8, and lets it read your existing schema.prisma. You then sign the database, move routes one at a time, and hand migrations to Prisma 8 only when you choose. !The five phases of a Prisma 7 to Prisma 8 migration: prepare Prisma 7 as prisma7, add Prisma 8, move routes one at a time, transfer migration ownership with db sign and migration plan, then remove Prisma 7 This is the path from Prisma's official Prisma ORM 7 to 8 guide, and the prisma8-and-7-example repo shows each phase. My test app was a Hono API on Prisma 7.10.1 with @prisma/adapter-pg, PostgreSQL 17.11, Node.js 24.22.0, a Role enum, a DateTime @default(now()), a Json? column and an increment update. Step 1: Run orm init npx prisma@latest orm init --from-prisma7-schema prisma/schema.prisma Write prisma@latest in full, because inside a Prisma 7 project npx prisma still runs version 7. In CI or from a coding agent, the command stops and asks for consent: CLI.CONSENT_REQUIRED: "Prisma 7 is installed as `prisma`. Keep it as @prisma/prisma7 (binary prisma7) and move `prisma` to Prisma 8, and rename prisma.config.ts to prisma7.config.ts?" requires explicit consent, and the session is not interactive. Grant it by passing --confirm app. Note that it had already added @prisma/orm-postgres to package.json before it stopped. With --confirm app it finished and changed exactly this: "dependencies": { "@prisma/adapter-pg": "^7.10.1", "@prisma/client": "^7.10.1", + "@prisma/orm-postgres": "^8.0.0-rc.18", }, "devDependencies": { + "@prisma/cli-engine": "^0.7.0", + "@prisma/prisma7": "^7.10.1", - "prisma": "^7.10.1", + "prisma": "^8.0.0-rc.23", } It renamed prisma.config.ts to prisma7.config.ts (now importing @prisma/prisma7/config), wrote a new prisma.config.ts, and emitted the client into src/prisma/: // prisma.config.ts (written by orm init) import "dotenv/config"; import { definePrismaConfig } from "@prisma/cli-engine"; import { defineConfig as ormConfig, prisma7Schema } from "@prisma/orm-postgres/config"; export default definePrismaConfig({ orm: ormConfig({ contract: prisma7Schema("prisma/schema.prisma"), output: "src/prisma", db: { connection: process.env["DATABASE_URL"]! }, }), }); npx prisma --version now reports 8.0.0-rc.23, and npx prisma7 generate still writes the Prisma 7 client. Update every script and CI step that must keep using Prisma 7 to call prisma7. Step 2: Sign the database $ npx prisma db sign ✔ app: signed b3b45c6c5fd8… (no marker before) ✔ Database signed ✔ Advanced ref "db" → b3b45c6c5fd8… $ npx prisma db verify ✔ Database marker and schema match contract db sign changes no tables. It adds a prisma_contract.marker table that records which contract hash the database satisfies. Prisma 7 still owns migrations, so after every prisma7 migrate dev or prisma7 migrate deploy, run npx prisma contract emit and npx prisma db sign again. Step 3: Move one route // src/routes/users.ts — now on Prisma 8 import { db } from "../prisma/db.ts"; users.get("/", async (c) => { const result = await db.orm.public.User.include("posts", (posts) => posts.orderBy((post) => post.id.asc()), ) .orderBy((user) => user.id.asc()) .all(); return c.json(result); }); users.post("/", async (c) => { const body = await c.req.json<{ email: string; name?: string }>(); try { return c.json(await db.orm.public.User.create(body), 201); } catch (error) { // No P2002 in Prisma 8: check the PostgreSQL SQL state instead if (error instanceof Error && "sqlState" in error && error.sqlState === "23505") { return c.json({ error: "email already exists" }, 409); } throw error; } }); The posts route stayed on Prisma 7, including its increment. A post written through Prisma 7 appeared in the next Prisma 8 read, and a duplicate email returned my 409. tsc --noEmit passed on TypeScript 6.0.3 and, as a bonus, on TypeScript 7 7.0.2. Step 4: Hand migrations to Prisma 8 When you are ready, convert the Prisma 7 schema into a real contract, point the config at it, sign, then plan a change: npx prisma contract print --output prisma8/contract.prisma # set contract: "prisma8/contract.prisma" in prisma.config.ts npx prisma contract emit npx prisma db sign The printed contract produced the same hash as the Prisma 7 schema (unchanged, already signed), so nothing drifted. It mapped my types like this: // use prisma-8 namespace public { model User { id Int @id @default(autoincrement()) email String name String? role pg.enum(Role) @default("USER") createdAt TimestampString(3) @default(now()) posts Post[] @@index([email], map: "User_email_key", unique: true) } native_enum Role { USER = "USER" ADMIN = "ADMIN" } } Then I added bio String? and ran the new migration loop: $ npx prisma contract emit $ npx prisma migration plan --name add_user_bio → Review migrations/app/20261017T1408_baseline and migrations/app/20261017T1409_add_user_bio $ npx prisma db migrate --advance-ref db ✔ Applied 1 migration(s) (1 operation(s)) across 1 contract space(s) ├─ Add column "bio" to "User" $ npx prisma db verify ✔ Database marker and schema match contract The first plan writes a baseline (the schema Prisma 7 built) plus your change. db migrate skips the baseline because the marker already records it. Each migration is a reviewable migration.ts: override get operations() { return [ this.addColumn({ schema: "public", table: "User", column: col("bio", "text", { codecRef: { codecId: "pg/text@1" } }), }), ]; } The Prisma 7 routes kept working after the new column. From here, retire prisma7 migrate from your scripts, move the remaining routes, and finally remove @prisma/prisma7, @prisma/client and @prisma/adapter-pg. What broke when I ran Prisma 7 and 8 side by side? Two things the guide doesn't warn about. First, orm init needs --confirm app in any non-interactive shell (CI, Docker, coding agents). Second, createdAt timestamps written by Prisma 8 were 5 hours off. Prisma 7 fills @default(now()) in the client in UTC, but Prisma 8 leaves it to the database, which used my server's local time zone. The evidence, from the same User table: id | createdAt written by 1 | 2026-10-17 14:06:44.701 Prisma 7 (UTC) 2 | 2026-10-17 19:08:52.282 Prisma 8 (server time zone Asia/Karachi, UTC+5) 4 | 2026-10-17 14:09:08.795 Prisma 7 (UTC) Prisma 7 created the column as TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, which is timestamp without time zone. Prisma's own mapping table says @default(now()) in Prisma 8 "is a database default." For a timestamp column, PostgreSQL then writes the time in the session's TimeZone setting, which defaults to the server's. After ALTER DATABASE p8demo SET timezone TO 'UTC', Prisma 8 wrote 14:09:20 at 14:09:20 UTC. Many managed PostgreSQL services default to UTC, so you may never see this. Check before mixing writers: SHOW timezone; -- must be UTC (or Etc/UTC) while Prisma 7 and 8 both write Also note the data type change: read through prisma7Schema(...), DateTime comes back as a string such as "2026-10-17 14:06:44.701", not a Date. My JSON responses changed format between the two routes (2026-10-17T14:06:44.701Z from Prisma 7), so API clients that parse dates should be tested. Should I upgrade to Prisma 8 now? Not for production apps yet. Pin Prisma 7 today, because that protects you from the latest tag change, and plan the move after GA. Start with Prisma 8 now only for new PostgreSQL projects that don't need the missing features, or to trial it on one route of an existing app with the side-by-side setup. !Decision flow for Prisma 8: stay on Prisma 7 for MySQL, SQL Server or CockroachDB, or if you use $extends, nested updates, increment, JSON filters or P2002 codes; otherwise trial Prisma 8 side by side or start new PostgreSQL projects on it | Your situation | Recommendation | | --- | --- | | Prisma 6 | Upgrade to Prisma 7 before November 19, 2026 | | Prisma 7 on MySQL, SQL Server or CockroachDB | Stay on 7; Prisma 8 doesn't support them yet | | Prisma 7 using $extends, nested updates, JSON filters or P2002 | Stay on 7 until those have replacements you accept | | Prisma 7 on PostgreSQL, simple CRUD | Pin 7 now; trial 8 on one route after GA | | New PostgreSQL project | Prisma 8 is reasonable; expect small API edits until GA | | Using Accelerate | Switch connections before December 1, 2026 regardless | What happens to Prisma Accelerate? Prisma retires Accelerate on December 1, 2026, according to its October 2 changelog. If your connection string starts with prisma+postgres://accelerate.prisma-data.net, switch to a pooled connection or the serverless driver before then. Accelerate's query caching has no replacement, so remove cacheStrategy from your queries first. The same changelog sets a second deadline: Prisma Postgres Early Access databases, the ones still on PostgreSQL 16, "are deleted on November 1, 2026 at 00:00 UTC." Move each one to a new database before then. Both deadlines apply whether you stay on Prisma 7 or move to 8. Prisma 8 upgrade checklist Pin Prisma 7 first, then handle the deadlines, then migrate on your own schedule. These steps follow the official guide plus what I hit in testing. 1. Pin prisma and @prisma/client to ^7 and replace every unpinned npx prisma in CI and Dockerfiles with npx prisma@7 or a lockfile install. 2. Leave Accelerate before December 1, 2026, and move Early Access Prisma Postgres databases before November 1. 3. Check requirements: Node.js 22.18+, 24.11+ or 26+, TypeScript 5.9+ with strict, PostgreSQL. 4. Audit for missing features: $extends, increment, nested updates, JSON filters, isolation levels, P2002 handling. 5. Check the database time zone with SHOW timezone; and set it to UTC if Prisma 7 and 8 will both write. 6. Run npx prisma@latest orm init --from-prisma7-schema prisma/schema.prisma (add --confirm app in CI). 7. Run npx prisma db sign, then move one low-risk route to db.orm. 8. After each prisma7 migration, run prisma contract emit and prisma db sign. 9. Transfer migrations with contract print, db sign, migration plan, db migrate --advance-ref db. 10. Remove Prisma 7 when nothing imports @prisma/client. Common Prisma 8 mistakes The most common mistakes are letting prisma@latest slip into a Prisma 7 build, running Prisma 8's db init or db update against a database Prisma 7 already manages, forgetting to re-sign after a Prisma 7 migration, and assuming DateTime and error handling behave the same in both clients. | Mistake | Symptom | Fix | | --- | --- | --- | | Unpinned prisma in CI | No command registered for generate | Pin ^7 or use npx prisma@7 | | orm init in CI without consent | CLI.CONSENT_REQUIRED | Add --confirm app | | db init / db update on a Prisma 7 database | Skips the signed handoff; the guide says to run neither | db sign, then the phase 4 handoff | | Not re-signing after prisma7 migrate | db verify reports a contract mismatch | contract emit, then db sign | | Catching P2002 in moved routes | Unique violations crash as 500s | Check error.sqlState === "23505" | | Server time zone not UTC | Prisma 8 timestamps offset by hours | ALTER DATABASE ... SET timezone TO 'UTC' | | Expecting Date objects | Strings or Temporal.Instant instead | Convert at the API boundary | | Hand-written contract on Node.js 24 | Temporal is undefined | import "temporal-polyfill/full/global" | Related: I benchmarked Prisma 8 RC against Prisma 7 and Drizzle in Drizzle vs Prisma in 2026: Prisma 8 RC had the slowest bundled cold start (about 370 ms). If you use Better Auth, note that Better Auth 1.7 supports Prisma 5 to 7 but not Prisma 8 yet; see my Better Auth with Next.js 16 setup. Related: Prisma's @default(uuid(7)) generates IDs in the client and sets no database default. On PostgreSQL 18 you can use dbgenerated("uuidv7()") instead; see my UUIDv7 in PostgreSQL 18 benchmark. Key takeaways - Prisma 8 is a release candidate (prisma 8.0.0-rc.23, @prisma/orm-postgres 8.0.0-rc.18 on October 17, 2026) with GA expected in October 2026, but npm's latest tag already installs it. - Pin prisma and @prisma/client to ^7 today; the Prisma 8 CLI has no generate, migrate or db push. - Prisma 8 replaces schema.prisma with a contract, prisma generate with prisma contract emit, and @prisma/client with @prisma/orm-postgres and chained queries. - $extends, increment, most nested writes, JSON filters, isolation levels and P2002 codes are missing, and only PostgreSQL is fully supported. - orm init --from-prisma7-schema runs Prisma 7 and 8 side by side on one database; it needs --confirm app outside an interactive terminal. - Check SHOW timezone before mixing writers: Prisma 8 leaves now() to the database, which skewed my timestamps by 5 hours. - Prisma 7 is supported for 18 months after Prisma 8 GA, Prisma 6 security patches end November 19, 2026, and Accelerate retires December 1, 2026. --- Originally published on fabwaseem.com.
8/ prisma/orm (★ 47.7k, formerly prisma/prisma) Next-gen ORM for Node.js & TypeScript: Postgres, MySQL, SQLite, MongoDB and more. One schema → typed client + migrations. prisma/orm
@BhagatDhanji I ran prisma for years, and now it's a dead and I would use it anymore. Prisma 8 is a drizzle copy basically so go with anything else. orm#30199 this kinda of issue I reported in 2024..
NestJS tip: how to try any official sample in seconds Let's say you want to run one of the official NestJS samples, the ones under the sample folder of the nestjs/nest repository, to see how some feature looks like in a real app. But you don't want to clone the whole framework just for that! What? Just run this: ## Node.js v22+ is required npx try-nest@latest Pick a sample, pick a directory, and optionally install the dependencies with npm, pnpm, yarn or bun. Each sample comes with its own description, so you don't need to guess what 18-context is about: ? Which sample would you like to try? ❯ 01-cats-app Guards, pipes, interceptors, filters and middleware in a REST API 02-gateways WebSocket gateway with Socket.IO and an optional Redis adapter 03-microservices Hybrid HTTP and TCP microservice with request-response messaging 04-grpc Hybrid HTTP and gRPC microservice with streaming and server reflection 05-sql-typeorm TypeORM integration with MySQL via @nestjs/typeorm 06-mongoose Mongoose integration with MongoDB via @nestjs/mongoose ... Guards, pipes, interceptors, filters and middleware in a REST API ↑↓ navigate • ⏎ select That's all! You'll end up with a standalone project that has only that sample's files, plus the next steps to run it. Why? All those samples live inside the nestjs/nest monorepo, next to the framework's source code. So, in order to run one of them, we usually clone the whole repo (or play with git sparse-checkout), cd into sample/<some-sample> and only then install & run it. Also, you need to know which sample you are looking for beforehand. Of course that you can use tools like degit to download a single folder, but you still have to browse GitHub to find out the sample's name first. How? try-nest does the following for you: 1. Reads the list of samples from the nestjs/nest repo at run time. There's no hardcoded list, so new samples show up as soon as they land on master 2. Reads the description field of each sample's package.json to annotate the list 3. Downloads the repo tarball and writes only the sample/<name>/ folder into your directory. Thus the result has no reference back to the monorepo Every prompt has a flag as well, so you can use it in scripts or CI: ## List all available samples ## (add --json for a machine-readable output) npx try-nest@latest --list ## Skip all the prompts npx try-nest@latest --sample 01-cats-app --dir my-cats-app --no-install which outputs: Done. 01-cats-app is ready in my-cats-app. Next steps: cd my-cats-app npm install npm run start:dev Upstream: https://github.com/nestjs/nest/tree/master/sample/01-cats-app --- This tool is heavily inspired by try-prisma. Check out the source code here: micalevisk/try-nest