Neon prices serverless Postgres as separate compute and storage meters

The workload

Running a Postgres database as a one-person SaaS means reading a pricing page closely enough to predict a bill before it arrives. Neon's pricing page, retrieved 16 September 2026, splits that job into two meters: compute and storage. A founder has to work out what a compute unit (CU) is, how CU-hours accumulate, and what happens once a database is split into branches for staging or preview environments. None of this requires hiring anyone; it is a documentation-reading task, repeated whenever the page changes.

What the documents show

Neon's pricing page states, verified, that the Free plan costs $0/month and includes 100 CU-hours and 0.5 GB of storage per project, with up to 10 branches. A CU is roughly 4 GB of RAM plus CPU and SSD, and a CU-hour is 'compute size × hours running' — the page's example is 0.25 CU for 4 hours equalling 1 CU-hour. On Launch and Scale, compute is billed at $0.106 and $0.222 per CU-hour, verified, and storage on both is $0.35 per GB-month, metered hourly, verified. Extra branches beyond the included 10 (Launch) or 25 (Scale) cost $1.50 per branch-month, prorated hourly, verified. The branching documentation adds, verified, that a branch is a copy-on-write clone that does not increase load on the parent, and warns that a longer history-retention window 'increases storage costs.' This site's existing entry on Supabase's plan-based pricing describes named monthly tiers rather than split meters; this entry only notes that structural difference, without restating those figures.

The operating cost

A founder on Launch pays $0.106 per CU-hour for compute and $0.35 per GB-month for storage, plus $1.50 per branch-month for any branch beyond the free 10. As an editorial estimate, not a Neon-published figure: five extra preview branches left running a full month add 5 × $1.50 = $7.50 to that bill, on top of their own compute and storage. Neon does not publish one combined 'typical bill' figure, since the two meters move independently.

The stop condition

The documents do not name a stop condition, so this one is editorial: because both branches and compute meter continuously by the hour, an idle branch left from a merged pull request keeps costing money until deleted. The practical trigger is the branch count itself — once a project holds more branches than the 10 included on Free or Launch, every additional one is a recurring line item, not a one-time cost, and deleting stale branches the day their pull request merges is the mechanism the documentation describes for stopping the meter.

• How many branches does the project actually need live at once, versus how many are dormant leftovers?
• Does the workload's compute usage fit inside the 100 free CU-hours, or does every month cross into paid CU-hour billing?
• Is the history-retention window set wider than the recovery scenario actually requires?

Neon's per-unit pricing rewards deleting what is no longer used and penalizes leaving branches or compute running by default. That is a documentation fact, not a performance claim, and it says nothing about how Neon's infrastructure behaves under load — only about what the meter counts.