Prisma Postgres vs Neon Pricing 2026: Per-Plan Tables and Worked Examples

Prisma Postgres and Neon are both serverless Postgres providers, and each is one of the main alternatives to the other. If you're trying to decide which is cheaper, the answer is a little annoying: they don't bill for the same thing, so it depends. This post gives you the side-by-side summary first, then per-plan detail with exact unit prices, then five worked cost examples with reproducible math, and finally a worksheet you can apply to your own workload.

They don't bill for the same thing. Prisma Postgres charges for how much you ask the database to do (operations). Neon charges for how long the database stays awake (compute-hours) plus storage. That's the core reason a line-by-line comparison isn't straightforward. The right answer depends on your usage shape.

The short version by workload: Neon is cheaper for mostly-idle, bursty, and very high-query-volume always-on workloads; Prisma Postgres is cheaper for user-facing apps with idle periods and latency-sensitive users at moderate query volumes, and its costs stay flat as query duration grows. The five worked examples below show the math for each.

At-a-glance: the two billing units (and why costs aren't directly comparable)

Prisma Postgres uses operations-based billing: every Prisma ORM query you execute counts as one operation, regardless of how long it takes to run. A single HTTP request that triggers three prisma.findMany() calls counts as three operations. The official definition from the Prisma pricing page: "An operation is each time you interact with your database, no matter the compute time. We count the Prisma ORM queries you make, not the SQL statements you run."

Neon bills on compute-hours (CU-hours): the product of how large your compute unit is and how many hours it stays active. A 1 CU database running for 10 hours consumes 10 CU-hours; a 2 CU database running the same 10 hours consumes 20 CU-hours. Neon's compute autosuspends after 5 minutes of inactivity by default on every plan (paid plans can disable it, and Scale can tune the interval from 1 minute to always-on), so idle time doesn't accumulate CU-hours. Storage is a separate line item on both platforms.

The practical implication: your Prisma Postgres bill is determined by how many ORM queries your code issues per month. Your Neon bill is determined by how large your database compute is and how many hours it stays awake. A query-heavy app with a small dataset that runs only a few hours a day looks very different on each model.

Per-plan pricing tables (2026): Prisma Postgres vs Neon

Prisma Postgres plans

Egress is free on every Prisma Postgres plan. Operation quotas are account-level, not per-database. The per-operation overage rate drops significantly as you move up plans: Starter charges 8x more per overage operation than Business.

Neon plans

Neon's Launch and Scale plans have no fixed monthly base fee; you pay for what you use each month. A very quiet month can genuinely cost a few dollars.

Other cost drivers to account for

Neon's history window is the storage used to retain WAL data for instant restore (point-in-time recovery). It's billed separately from your live database storage at $0.20/GB-month, and grows with the size of your data and how long you retain history. This is easy to overlook when estimating Neon costs.

Worked example 1: hobby / low-traffic app

Assumptions:

• 500 requests/day
• 3 Prisma ORM queries per request
• 28-day month (to keep math clean)
• 2 GB database storage
• Neon: 0.25 CU average size (minimum), active ~6 hours/day (autosuspends otherwise)

Prisma Postgres (Starter plan):

Operations/month = 500 requests × 3 queries × 28 days
                 = 42,000
Included         = 1,000,000              → no overage
Storage          = 2 GB (10 GB included)  → no overage

Monthly cost     = $10.00 (plan base only)

Neon (Launch plan):

CU-hours/month   = 0.25 CU × 6 h/day × 28 days
                 = 42 CU-hours
Compute          = 42 × $0.106      = $4.45
Storage          = 2 GB × $0.35     = $0.70
History window   = 0.5 GB × $0.20   = $0.10  (assumed retention)

Monthly cost     ≈ $5.25

At this traffic level, Neon is cheaper because the operation count fits well under Prisma's Starter inclusion, but the $10 base fee on Starter isn't offset by usage. If you don't need the Starter base features and your traffic is this low, Neon's usage-based model wins on raw cost. If you're already on Prisma's free tier (100k operations), that covers this workload at $0.

Worked example 2: steady production API

Assumptions:

• 50 requests/second sustained (24/7)
• 4 Prisma ORM queries per request (auth check + 3 data fetches)
• 30-day month
• 20 GB database storage
• Neon: 1 CU or 2 CU average (database stays awake; no autosuspend benefit)

Prisma Postgres (Pro plan):

Operations/month = 50 req/s × 4 queries × 86,400 s/day × 30 days
                 = 518,400,000
Included on Pro  = 10,000,000
Overage          = 508,400,000 / 1,000 × $0.0020
                 = $1,016.80
Storage          = 20 GB (50 GB included)  → no overage

Monthly cost     = $49.00 + $1,016.80 = $1,065.80

Sensitivity check: add 1 more query/request (5 queries total):

Operations/month = 50 req/s × 5 queries × 86,400 s/day × 30 days
                 = 648,000,000
Overage          = +$259.20/month vs the 4-query case

Neon (Launch plan, 1 CU always awake):

CU-hours/month   = 1 CU × 24 h × 30 days
                 = 720 CU-hours
Compute          = 720 × $0.106     = $76.32
Storage          = 20 GB × $0.35    = $7.00
History window   = 5 GB × $0.20     = $1.00  (assumed)

Monthly cost     ≈ $84.32

Sensitivity: 2 CU always awake:

CU-hours/month   = 2 CU × 24 h × 30 days
                 = 1,440 CU-hours
Compute          = 1,440 × $0.106   = $152.64

Monthly cost     ≈ $160.64

Note that Neon's compute sizes and autoscaling ranges are plan-dependent; Scale plan compute is $0.222/CU-hour, which roughly doubles those figures.

For a high-throughput, always-on API with many Prisma ORM queries per request, Neon's compute-hour model is dramatically cheaper. Prisma Postgres's operations-based pricing becomes expensive when the per-request query count is high and traffic runs continuously. You'd want to look at query batching and reducing per-request ORM call count if you're staying on Prisma Postgres at this scale.

Worked example 3: bursty workload / intermittent usage

Assumptions:

• Active 4 hours/day (e.g., business-hours tool), idle the rest
• During active window: 20 requests/second, 3 Prisma queries/request
• 1 CU during active window; autosuspend kicks in when idle
• 30-day month, 5 GB storage

Prisma Postgres (Starter plan):

Operations/month = 20 req/s × 3 queries × 14,400 s/day × 30 days
                 = 25,920,000
Included         = 1,000,000
Overage          = 24,920,000 / 1,000 × $0.0080
                 = $199.36
Storage          = 5 GB (10 GB included)  → no overage

Monthly cost     = $10.00 + $199.36 = $209.36

Neon (Launch plan):

CU-hours/month   = 1 CU × 4 h/day × 30 days
                 = 120 CU-hours   (idle ≈ $0: autosuspend after 5 min)
Compute          = 120 × $0.106     = $12.72
Storage          = 5 GB × $0.35     = $1.75
History window   = 1 GB × $0.20     = $0.20  (assumed)

Monthly cost     ≈ $14.67

This is where Neon's autosuspend model has a clear advantage. Because the database is genuinely idle for 20 hours a day, Neon only charges for the 4 active hours. Prisma Postgres still charges per operation regardless of the time dimension, so the 25.9M monthly operations in the active window accumulate significant overage. If your total monthly operation count were lower (say, lighter traffic during those 4 hours), the Starter plan might work, but at 20 RPS with 3 queries/request the overage adds up fast.

From the Prisma perspective: operation-based pricing is predictable in a different direction. You can cap spend by limiting total operations via spend controls, which makes budgeting deterministic regardless of when those operations happen.

Worked example 4: user-facing app with idle periods and latency-sensitive users

Assumptions:

• Consumer web app: traffic clusters in waking hours, quiet overnight
• ~0.5 requests/second on average across the month, 3 Prisma ORM queries per request
• Users are always waiting on the response, so a cold start in front of a request is not acceptable
• 30-day month, 5 GB storage

Prisma Postgres (Starter plan):

Operations/month = 0.5 req/s × 3 queries × 86,400 s/day × 30 days
                 = 3,888,000
Included         = 1,000,000
Overage          = 2,888,000 / 1,000 × $0.0080
                 = $23.10
Storage          = 5 GB (10 GB included)  → no overage

Monthly cost     = $10.00 + $23.10 = $33.10

Neon (Launch plan, auto-suspend disabled):

CU-hours/month   = 1 CU × 24 h × 30 days
                 = 720 CU-hours   (always-on: users can't wait for wake-ups)
Compute          = 720 × $0.106     = $76.32
Storage          = 5 GB × $0.35     = $1.75
History window   = 1 GB × $0.20     = $0.20  (assumed)

Monthly cost     ≈ $78.27

This is the workload shape operation-based billing is built for, and the one the previous examples skip. The app has real idle time, but users are waiting on every query, so Neon's autosuspend advantage is off the table: enable it and your users eat cold starts; disable it and you pay for every hour, including the quiet ones. Prisma Postgres charges for the 3.9M queries and nothing else, so the idle hours are free and the database is always ready. At these assumptions it comes out at less than half of Neon's always-on cost.

Two honesty notes. If your app genuinely fits Neon's 0.25 CU minimum around the clock, always-on drops to about $21/month all-in and the comparison inverts in Neon's favor; the $33-vs-$78 result rests on 1 CU being the realistic floor for latency-sensitive production traffic with bursts, so size that against your real load, not the average. And the advantage flips back as query volume grows: past roughly 24M operations a month (against the $49 Pro plan at 1 CU), always-on compute becomes the cheaper option again, as in example 2.

Worked example 5: analytics-heavy / read-heavy job

Assumptions:

• 50 scheduled analytics queries/day (long-running scans, not interactive)
• Each job: 1 Prisma ORM query (a single prisma.$queryRaw or findMany with complex filters)
• Jobs run for ~5 minutes each
• 50 GB database storage
• Neon: 2 CU during active jobs, otherwise suspended

Prisma Postgres (Pro plan):

Operations/month = 50 queries/day × 30 days
                 = 1,500
Included on Pro  = 10,000,000             → no overage
Storage          = 50 GB (50 GB included) → no overage

Monthly cost     = $49.00

Neon (Launch plan):

Active time      = 50 jobs/day × 5 min × 30 days
                 = 7,500 minutes = 125 hours
CU-hours/month   = 2 CU × 125 h    = 250 CU-hours
Compute          = 250 × $0.106     = $26.50
Storage          = 50 GB × $0.35    = $17.50
History window   = 10 GB × $0.20    = $2.00  (assumed)

Monthly cost     ≈ $46.00

At these assumptions the two land at rough parity ($46 vs $49), and the interesting part is the trend, not the totals. Prisma's operation count is trivial (1,500) and stays flat no matter how long each job runs. Neon's bill scales with job duration: if those jobs run 30 minutes instead of 5, compute rises to about $159 and the monthly total to roughly $178, while Prisma's stays at $49. A 50 GB dataset also generates meaningful storage and history-window costs on Neon.

Important caveat: Prisma Postgres has query timeout limits: pooled queries time out at 10 minutes, while direct connections have no timeout. Long-running analytics scans that exceed the pooled timeout will error. If your analytics workload involves queries running for minutes, check the connection docs before assuming cost is the only variable. For heavy analytical workloads sitting alongside an interactive app, the standard recommendation is to separate the two: run analytics on a read replica or a dedicated OLAP store, and keep your application database for interactive queries.

How to run your own estimate

Inputs to gather

• Monthly requests (HTTP requests, cron jobs, background tasks that hit the DB)
• Prisma ORM queries per request (count prisma.* calls in a typical request handler; this is your operation-count multiplier)
• Storage in GB-months (average GB stored over the month)
• For Neon: expected CU size (0.25, 0.5, 1, 2, or more) and active hours/day (hours the DB is awake vs. suspended)
• For Neon: branches in use and whether you're using instant restore (history window size)
• Egress expectations (Neon meters public network transfer above 500 GB/month)

The math

Prisma Postgres:

Operations/month = monthly_requests × queries_per_request
Cost = plan_base + max(0, operations - included) / 1000 × overage_rate
     + max(0, storage_GB - included_GB) × storage_rate

Neon:

CU-hours/month = avg_CU_size × active_hours_per_day × days_per_month
Cost = CU-hours × compute_rate
     + storage_GB × $0.35
     + history_window_GB × $0.20
     + extra_branches × $1.50
     + max(0, egress_GB - 500) × $0.10

Links to official calculators

• Prisma pricing page and calculator: enter your estimated operations and storage; the calculator maps directly to the per-plan rates above.
• Neon plans documentation: includes worked bill examples for Launch and Scale showing compute CU-hours, storage (root/child branches), instant restore history, and resulting amount due.

Sanity checks

• Prisma: count Prisma ORM method calls (.findMany(), .create(), .update(), etc.), not raw SQL statements. One prisma.user.findMany() is one operation even if it compiles to a complex JOIN.
• Neon: model active hours, not total calendar hours. If your database autosuspends during idle periods, your CU-hour count is much lower than 24 × 30 = 720 per month.
• Neon history window: don't forget this line item. A 20 GB database with a 7-day history window on a write-heavy app can accumulate several GB of WAL history, adding meaningful storage cost at $0.20/GB-month.
• Extra branches: if you use Neon branches for preview environments or CI, each extra branch past the plan's included count is $1.50/branch-month. Ten preview branches add $15/month before compute.

What developers are saying about Prisma Postgres and Neon pricing

Neon's usage-based model rewards spiky workloads by design. Per Neon's own autoscaling report (December 2025 data), the average production database on its platform used about 2.4x less compute than a fixed instance sized 20% above its P99.5 load. The flip side is the pattern in the examples above: an always-on small app pays for every hour.

Prisma Postgres drew a mixed reception on Hacker News at launch. Some developers liked the per-operation model (a complex query with five CTEs still counts as one operation), others found the launch pricing confusing, and several flagged query-timeout limits as a dealbreaker for analytics-style queries. That last point is fair: Prisma Postgres is built for interactive application queries rather than long-running analytical scans. If you need heavy analytics alongside your app, evaluate the architecture separately from the cost comparison.

So which is cheaper?

It depends on the shape of your usage, not the headline numbers. The worked examples above show the pattern clearly:

• Low traffic, mostly idle: Neon's usage-based model often wins because you don't pay a base fee and the CU-hour count stays low.
• High query-per-request ratio, sustained traffic: Neon's compute-hour model can be dramatically cheaper because it doesn't scale with query count.
• Bursty active windows: Neon's autosuspend gives it an edge when the database is genuinely idle most of the day.
• Idle periods with latency-sensitive users: the shape operation billing is built for. Neon has to run always-on (about $77/month per CU) to avoid cold starts in front of users, while moderate query counts stay inside Prisma's plan allowances (example 4: $33 vs $78 at 1 CU; an app that truly fits 0.25 CU inverts it).
• Analytics / long-running queries: roughly at parity at short job lengths, then Prisma's flat operation count wins as jobs lengthen, since Neon's compute cost scales with duration. Check Prisma's timeout limits before assuming it's the right fit.
• Predictability and budget controls: Prisma Postgres's operation-based model is easier to estimate in advance, and spend limits make cost caps deterministic.

One thing the tables leave out: the database is usually one line item in a larger stack. Prisma bundles ORM, Postgres, and app Compute into one platform and one bill, which can simplify total infrastructure cost if you're comparing whole stacks rather than databases alone.

Don't trust a summary over your own math. Plug your real traffic into the calculators before you commit. Prices change, especially usage rates, so verify against the Prisma pricing page and Neon plans docs for current figures.

FAQ