Neon pricing

Your questions,
answered

• What is a project?

  A project in Neon is the top-level container for your database environment. Each project includes your primary database, its branches, and compute resources. You can think of it like a GitHub repo: one project, many branches. Learn more about Neon's object hierarchy.

• What is a CU?

  A CU (short for Compute Unit) is Neon's way of representing compute size. It defines how much CPU and memory your database is using at any moment. Each CU allocates approximately 1 vCPU and 4 GB of RAM. Learn more about compute sizing on Neon.

• What is a CU-hour?

  A CU-hour is Neon's unit for measuring compute usage.

  Because Neon is a serverless database, you're billed only for the compute resources you actually use. In other words, your monthly compute usage depends on:

  • How many compute endpoints are you running
  • How large your compute endpoints are (in CUs)
  • How long they run (in hours)

  For a single compute, the calculation works similar to this:

  Monthly CU-hours = [average CU size] × [number of hours the compute runs in the month] Monthly compute cost = [monthly CU-hours] × [CU-hour price]

  The CU-hour price depends on your pricing plan:

  • Launch plan: $0.106 per CU-hour
  • Scale plan: $0.222 per CU-hour

  Remember that when your database is idle, compute can scale down to zero, so you don't consume CU-hours while it's not running. Learn more about Neon's billing.

• What does 100 CU-hours per project give me on the Free plan?

  On the Free plan, each project gets 100 CU-hours per month, and compute automatically scales down to zero when idle. What this means in practice:

  • You can create up to 100 projects, each with its own independent 100 CU-hour allowance
  • CU-hours are only consumed while a database is actively running queries. When a project is idle, compute scales to zero and uses no CU-hours
  • Usage is typically spread across short bursts of activity, not continuous runtime

  A realistic example for a single project:

  • The database runs at an average of 1 CU for ~3 hours per day. It scales down to zero the rest of the time
  • Over a month, this uses roughly 90 CU-hours, staying within the Free plan limits for that project

  This model is designed to make it practical to have many small or intermittent databases (for development, demos, previews, or experiments) without being forced into an upgrade. Learn more about our Free Plan philosophy.

• How are the workload cost estimates calculated?

  The typical monthly cost estimates shown in our pricing plans are based on representative database workloads that reflect common usage patterns across different application types.

  Each estimate combines two components:

  • Compute cost: Based on the specified CU-hours per month.
  • Storage cost: Based on the specified amount of database storage in GB.

  These estimates help you compare typical workloads across plans.

  Here's a detailed breakdown of each of the workload sizes and what they represent:

  Intermittent Load:

  140 CU-hours compute, 1 GB-month of storage. Typical of a small database that doesn't need to run 24/7. A databse using 140 CU-hours compute per month can scale to zero when idle, and start back up in 350ms when it's needed. When it's running it is set to a minimum size of 0.25 CU but can scale up to 2CU when needed.

  Low Load:

  190 CU-hours compute, 5 GB-month of storage. A small database that does need to run 24/7. Once scale to zero is disabled, the minimum CU-hours a database can use in a month is 187.5 (750 hours in a month x 0.25 minimum CU size = 187.5) so this example represents a database that has scale to zero disable but only occasionally needs to scale above the 0.25 minimum size. Good for small production applications and databases that need to be always-on for features like real-time sync.

  Medium Load:

  720 CU-hours compute, 10 GB-month of storage. Representative of a constant-load application database. As you can see from the autoscaling chart above, 720 CU hours translates to a database that scales between 0.5 and 4 CU based on load.

  High Load:

  3,000 CU-hours compute, 100 GB-month of storage. As an example, a database that is scaling between 3 CU and 7 CU will often use around 3000 CU hours in a month. This level represents production applications with sustained traffic, higher data volumes, and more complex queries requiring consistent compute resources.

  XL Load:

  6,000 CU-hours compute, 1,000 GB-month of storage. A database scaling between 6 and 14 CU can use in the range of 6,000 CU hours in a month. This is representative of large-scale production workloads with high traffic volumes, extensive datasets, and applications requiring significant compute capacity and storage.

  Your actual costs will vary based on:

  • How much your database autoscales based on actual query load
  • How long your computes run before scaling to zero
  • Your actual data size and number of branches
  • Your configured restore window (affects history storage costs)

  Remember that Neon bills based on actual usage, not estimates. Use these workload examples as reference points, then monitor your usage in the Neon Console to understand your real costs. Learn more about how Neon billing works.

• What does "no monthly minimum" mean on paid plans?

  Neon's paid plans don't require a minimum monthly spend or base fee. You're billed purely based on usage. If one month you barely use Neon, your bill might be just a few dollars.

  For example, if your databases are mostly idle that month, or you only run them briefly for development or testing, you'll only pay for the compute and storage actually consumed during that time. Remember that Neon databases scale to zero by default.

• Are the Free Plan quotas included in the paid plans?

  No. Neon's paid plans work independently of the Free plan.

  When you're on a paid plan, usage starts metering from zero for both compute and storage. Free plan quotas don't apply once you upgrade. Instead, you're billed purely based on actual usage, at the rates of your paid plan.

  You should consider a paid plan if:

  • You expect higher or more sustained usage than what's included per project on the Free plan
  • You care about production guarantees, such as consistent availability, predictable performance, and never having your database paused due to usage limits

  If your usage fits comfortably within the Free plan and you're not running a production workload, there's no reason to upgrade. The Free plan is designed to be genuinely useful for development and prototyping. Learn more about our Free Plan philosophy.

• How is storage billed in Neon?

  In Neon, you don't provision or manage storage in advance. Storage scales automatically and invisibly as your data grows. At the end of each month, you're billed for the storage actually consumed per project, measured in GB-months.

  Neon bills storage usage using two separate metrics:

  History storage (or instant restore storage)

  Neon retains a history of database changes so you can restore a branch to a previous point in time, create branches from past states, run time travel queries, and more. This history is controlled by your restore window, which is configurable per project (1 day by default in paid plans).

  History storage is billed based on the amount of Write-Ahead Log (WAL) history retained within your restore window, at $0.20 per GB-month on paid plans. This is billed separately from your regular database storage.

  If you don't need deep recovery or long time travel capabilities, you can shorten the restore window to reduce costs.

  Database storage (root and child branches)

  This is the storage used by your database data itself. Since Neon databases can branch, this is how branches contribute to database storage:

  • Root branches are billed based on their actual data size (for example, 5 GB)
  • Child branches might be billed based on the minimum of: the accumulated data changes since the branch was created, or the underlying storage footprint, which is zero if the branch is still within the restore window (in this case, the child branch effectively shares storage with its parent).

  The SUM of both components will be billed as your database storage at $0.35 per GB-month.

  What this implies:

  • A child branch that has no data changes compared to its parent and is still within the restore window does not incur additional database storage costs.
  • As a child branch accumulates changes over time, its storage usage increases.
  • If a child branch falls out of the restore window, it becomes as expensive as a root branch, since it no longer shares storage with its parent.

  To keep database storage costs low, child branches are best kept short-lived - for example, by setting expiration times, resetting them frequently, or deleting branches when they're no longer needed.

• How are extra branches billed?

  Each Neon plan includes a set number of branches per project at no additional cost (10 branches per project in Launch, 25 branches per project in Scale) but you can create and delete branches freely within your plan's included allowance:

  • If the total number of concurrent branches in a project exceeds your plan's allowance, the extra branches are billed as branch-months, prorated hourly.
  • The price is $1.50 per extra branch-month (≈ $0.002 per hour)
  • You're only billed for branches that exceed your included limit, and only for the time they exist.

  Example: The Launch plan includes 10 branches per project. If you already have 10 branches but create 2 additional branches and keep them for 5 hours each, that'd be 10 extra branch-hours total: 10 × $0.002/hour = $0.02

  How to avoid extra branch charges

  • Use branch expiration. Set automatic deletion times on temporary branches so they're cleaned up when no longer needed.
  • Automate cleanup. Use the Neon API or Neon CLI to periodically delete unused branches and stay within your included allowance.

• How is Neon Auth billed?

  Neon Auth is included at no additional cost for all Neon databases until you reach 1 million monthly active users (MAU). If you surpass that threshold, a member of our team will reach out to discuss pricing.

  On the Free plan, Neon Auth is included for up to 60,000 MAU.

• How can I control my costs?

  Compute is often the most variable part of a monthly bill. The most effective way to control compute costs in Neon is to configure maximum autoscaling limits and scale-to-zero.

  Autoscaling limits act as a built-in cost ceiling: your database will never scale beyond the limit you set, even during traffic spikes. If you want to prioritize performance over costs in a particular compute endpoint (e.g. production), choose a higher limit. If you want to optimize for cost predictability, set a lower one. Learn how to configure autoscaling limits.

  Another effective way to control compute costs is to ensure scale to zero is enabled for all non-production branches. When a branch is idle, compute scales down automatically, so you're not charged for unused databases. Learn about scale to zero.

  To manage storage costs, regularly clean up unused branches, snapshots, and projects, and avoid retaining large restore windows if not required by your use case. Learn more about optimizing storage usage.

• Do you offer credit programs for startups?

  Early startups that have received venture funding are eligible to apply to our Startup Program. Learn more and apply here.