### Neon pricing table with verified values I assembled the table on 2 November 2026 from Neon's pricing page and docs. Where I couldn't confirm a value, the cell says so. | | Free | Launch | Scale | |---|---|---|---| | Base price | No monthly fee | No minimum monthly fee, pay for what you use | No minimum monthly fee, pay for what you use | | CU-hours | Fixed included allowance, size unverified | Usage-based, allowance unverified | Usage-based, allowance unverified | | Storage | Capped, size unverified | Unverified | Unverified | | Projects | Limited, count unverified | Unverified | Unverified | | Branches | Limited, count unverified | Unverified | Unverified | | Autoscaling max | Lowest of the three, size unverified | Unverified | Highest of the three, size unverified | | Restore window | Shortest of the three, length unverified | Unverified | Longest of the three, length unverified | | Support | Community | Unverified | Unverified | | Compliance | Not the tier for regulated workloads | Unverified | Unverified | Read the table in two passes. First compare the rows that scale with load: CU-hours, storage and branches. Those decide your bill. Then compare restore window and compliance, which decide whether a plan is safe for production at all. Since Databricks acquired Neon, pricing has moved. Check any older comparison or blog post against the live page. ## What Neon costs at realistic usage, against alternatives Run your hours through the meter and the bill lands in one of three places: - The bill is close to nothing for an idle app - The bill is mostly compute for an always-on API - The bill is cheapest of the comparison set for branch-heavy workflows ### Small app that sleeps most of the day When an app sits idle most of the day, almost nothing goes to compute, because Neon meters CU-hours and an idle database stops accruing them. What remains is storage, so a small app's bill is set by how much data it holds, not how long the project has existed. ### Always-on production database $121.38 a month is about what an always-on 100 GB database on Launch costs, and compute is most of it, so cost control requires managing compute. [PriceHiked](https://pricehiked.com/tool/neon) breaks that down as $77.38 for compute, $35 for storage and $9 for backups.  Trim CU-hours (a smaller autoscaling ceiling, for instance) and you save more than any amount of data cleanup, because **compute is roughly 64% of the bill**. ### Neon database branches for pull request previews **$3 a month buys a database** for every pull request on Neon, against $20 on PlanetScale and $39 on Supabase, according to a [DEV Community comparison](https://dev.to/kubeden/neon-vs-supabase-vs-planetscale-vs-aws-what-postgres-costs-in-2026-59o5), which means Neon's pricing makes per-PR databases the economical choice for any CI/CD pipeline.  Branches share storage with their parent, which is the mechanism keeping the Neon number low. ### Neon next to Supabase, Aurora and PlanetScale About $17 a month covers 50 mostly idle per-customer databases on Neon, which means idle database sprawl doesn't significantly impact costs. Aurora is about $31, PlanetScale $250, Supabase $515 and RDS about $700. Near the low end sit only Neon and Aurora, because both scale compute down when idle. The other three charge for provisioned capacity, so 50 databases that are quiet most of the day still bill around the clock.  Idle fleets and per-PR branches favor Neon, while an always-on database narrows the gap. So the cheapest platform depends on the shape of your usage, which is the reason to size your plan from your own CU-hours before comparing logos. ## Hidden Neon costs and limits teams hit Small teams get surprised by five things: cold starts after idle, autoscaling that lifts compute hours, branch and history storage, data transfer, and connection limits. - 5-minute autosuspend cold starts - autoscaling raising CU-hours - branch and history storage ($1.50/branch-month, $0.20/GB-month) - data transfer - connection limits ### Neon cold starts and scale-to-zero trade-offs After 5 minutes idle, a compute suspends and the next query waits while it restarts, so any pause longer than 5 minutes forces a cold restart. For a production app with steady users, though, the first visitor after a quiet spell eats the delay. The fix is to keep the compute awake, and that turns an idle-priced database into an always-on one billed for every hour. When load pushes compute above its minimum, CU-hours rise with it, so autoscaling adds a second effect: a traffic spike shows up in the bill as well as in performance. A spike like that is easiest to catch before the allowance is gone, and Activepieces can run the watch for you: a workflow that polls Neon's API for usage and posts to Slack or email before the plan's allowance runs out. Activepieces meters the run and not the steps inside it, so a poll, a threshold test and an alert cost 1 credit, the same as one cramped step would, and the Free plan's 1,000 credits a month covers a weekly check many times over.  Zapier's per-task billing charges for each of those steps, which is how a tidy check becomes a line item; either way it's a monitoring convenience that does nothing to Neon's pricing, and the Monday section below covers where it fits. ### Storage growth from branches and history Storage is metered in two places. According to Neon, each branch costs $1.50 per branch-month, so a team that opens a branch per pull request and never deletes them pays for every stale one.  At $0.20 per GB-month, stored data and retained history quietly grow the storage line, so teams need explicit retention policies to prevent bill creep. The habit that keeps this flat is deleting merged branches and setting history retention to the shortest window you can recover from. ### Neon connection limits and connection pooling Connection limits rise with compute size, according to the [Neon docs](https://neon.com/docs/connect/connection-pooling): | Compute size | Connections allowed | |---|---| | 0.25 CU | 104 | | 1 CU | 419 | | 2 CU | 839 | | 4 CU | 1678 |  When many serverless functions each open their own connection, a small compute can run out of direct connections. Using the pooled connection string is the cheaper first move, and sizing up is the second. ### Neon features locked to paid plans Some controls sit behind paid plans rather than Free. Turning off autosuspend to avoid cold starts is the one most production teams want first, and it's the strongest argument for the entry paid plan. ## Checking your Neon bill on Monday One pass through the usage page, two compute settings and a branch cleanup is all it takes to check your Neon bill. It ends with a decision about whether your plan still fits. ### Read the usage page against your plan Open Billing and then Usage in the console. Neon meters compute hours and storage, so those are the two lines to find. Put each beside the allowance your current plan includes. 1. Note compute hours used so far this period and divide by the days elapsed. That's your daily rate, and projecting it forward shows whether you finish the month inside the allowance or over it. 2. Note storage and compare it with the plan's included amount. Storage tends to climb steadily, so a figure near the limit now will be over it soon. 3. Check which database or branch is consuming most of the compute. One busy branch usually explains the whole line. ### How to cut Neon costs easily Set the autoscaling maximum on each production compute to the size your heaviest real query needs, not the largest option. Then set the suspend timeout. A compute that sleeps when idle stops accruing hours, so a short timeout on staging and development databases saves directly. Keep production awake if cold-start latency would be visible to your users, and accept the hours that cost. Finally, delete stale branches. Every branch holds data that counts toward storage. Delete anything nobody has touched since its pull request closed. ### Optional: automate a usage alert If you wouldn't rather not remember this every Monday, a workflow automation tool can do the check for you. Schedule a recurring call to Neon's API for your project's consumption, compare the result with a threshold you choose, and post to team chat or send an email when it crosses. That's optional. The manual check above costs a few minutes, and the decision it feeds is what matters: if usage keeps pressing against the allowance, move to the plan whose allowance matches it. ## What Activepieces does about this The problem in this article is a bill that drifts toward the edges without anyone watching it: compute hours creeping up under autoscaling, stale branches accruing at $1.50 a branch-month, storage nearing the allowance, so by the time anyone notices, months of spending have gone unwatched. Activepieces doesn't change Neon's pricing, and I won't pretend it does. What it does is make the Monday check above something that runs without you remembering it. The build is small. A scheduled flow calls Neon's API for your project's consumption, compares compute hours and storage with a threshold you set against your plan's allowance, and posts to Slack or sends an email when the number crosses. A second flow can list branches and flag any older than a set age, so the stale ones get deleted before they bill. Activepieces meters a run, not the steps inside it, so the poll, the threshold test and the alert together count as one credit. The Free plan's 1,000 credits a month covers a weekly check many times over.  Activepieces is open source under the MIT licence, with the community edition on GitHub, so you can self-host the flows next to your database instead of paying for a hosted tier. That matters here because the whole point of the check is to stay below the line where a small team starts paying for tooling it didn't need. If you'd rather not run anything, the hosted Free plan does the same job. None of this replaces sizing the plan from your own CU-hours. Do that first. Then let the flow watch the meter, so that if usage keeps pressing against the allowance you hear about it while moving up a tier is still a choice, not a surprise invoice. ## Frequently asked questions For each question the body leaves open, the table gives a short answer and the page that governs it. You can confirm the answer against Neon's own wording before you commit to a plan. | Question | Short answer | Source page | |---|---|---| | Is Neon free for production use? | The Free allowance is sized for small workloads; most small teams running production should use the entry paid plan | Neon pricing page | | Does Neon charge when the database is idle? | Compute stops billing when suspended; storage keeps billing | Neon pricing page, billing docs | | Can I downgrade from paid to Free? | Check the console before upgrading | Neon billing docs | | Do discounts exist? | Treat list price as the price unless Neon says otherwise | Neon pricing page | | What happens over the limits? | Free restricts you; paid plans meter the overage | Neon plans docs | Because plan names and limits change, each answer below points you to the page to recheck. ### Is Neon free for production use? If the workload fits inside the Free allowance, Neon is free for production use, but a production app sits close to that ceiling with no margin. You pay with limits instead of dollars, and the first traffic spike is when you find out how tight they are. ### Does Neon charge when the database is idle? When a database is suspended, it uses no compute hours, so Neon doesn't charge for compute while it's idle: compute is metered in hours. Storage is metered separately and keeps accruing while the compute sleeps. A quiet database therefore costs less than a busy one, but never nothing on a paid plan. The cost of idling is the cold start on the first query after a suspend. ### Can I downgrade from paid to Free? Don't assume a downgrade from a paid Neon plan to Free is a one-click reversal. Your data has to fit within the Free limits first, so a project that's grown past them may need trimming before the switch. If you are testing a paid plan, check the downgrade path in the billing settings before you move real data onto it. ### Do discounts exist? To confirm any startup or annual-billing discount, the pricing page is the only place, and the body's math assumes list price. If a startup program or annual option exists when you read this, it lowers the cost of the entry paid plan. It doesn't change which plan matches your compute hours and storage. ### What happens if I go over my plan's limits? It depends on the plan, and the difference matters. **On Free, hitting a limit means restricted service**, so your app is what pays for it. On a paid plan, usage beyond the included allowance is billed as overage, so the cost is a bigger invoice instead of an outage. That's the main reason a team in production should pay for the entry plan: you trade a failure you can't predict for a bill you can estimate. ## Related reading - [DeepSeek Search API vs Exa Pricing for Small Teams (2026)](https://www.activepieces.com/blog/deepseek-search-api-vs-exa-pricing-for-small-teams-2026) - [No-Code Automation Statistics 2026: Adoption for Small Teams](https://www.activepieces.com/blog/no-code-automation-statistics-2026-adoption-for-small-teams) - [Neon MCP Server: How to Set It Up (2026 Guide)](https://www.activepieces.com/blog/neon-mcp-server-how-to-set-it-up-2026-guide) ## References - [Neon Docs](https://neon.com/docs/connect/connection-pooling) - [PriceHiked](https://pricehiked.com/tool/neon) - [DEV Community](https://dev.to/kubeden/neon-vs-supabase-vs-planetscale-vs-aws-what-postgres-costs-in-2026-59o5)Once a database scales to zero when idle, it stops accruing CU-hours, so an always-on production database costs far more than a dev database with the same schema.