Neon review

Neon is a Databricks backend platform built around Lakebase Postgres, a serverless database that can branch and scale with an app. The product reaches beyond the database: it includes managed authentication built on Better Auth, functions that run near the database without timeouts, and S3-compatible object storage that branches with projects. Its AI Gateway offers one API for frontier and open-source models and is powered by Databricks.

Neon also handles database compute scaling. The homepage says it monitors database load ten times a second and adjusts CPU and memory accordingly. Pricing is usage-based on the paid plans, with a free tier for building and learning. That breadth is the main pitch: database, auth, functions, storage and AI access in one backend platform. It is not a simple fixed-price Postgres plan, so expected usage matters when comparing costs.

Neon covers several backend pieces around Postgres rather than stopping at database hosting. Branching is part of the core product, and the listed object storage also branches with projects. Managed authentication, database-adjacent functions and an AI Gateway round out the package for teams building apps or agents. Whether that replaces separate tools depends on the requirements, but the components are clearly part of the offer.

The free plan is usable for small projects or evaluation: it includes 100 projects, 100 CU-hours per month per project, 1 GB of storage per project, up to 2 CU (8 GB RAM) and unlimited team members. Paid plans raise the compute ceiling: Launch goes up to 16 CU (64 GB RAM), while Scale goes up to 56 CU (224 GB RAM). Scale also lists HIPAA and private networking. For teams with variable demand, usage-based compute means the listed typical monthly spend is a reference point, not a fixed subscription price. That can suit intermittent workloads, provided the team tracks usage.

The main drawback is budgeting. Launch lists a typical spend of $15 per month, but bills $0.106 per CU-hour and $0.35 per GB-month of database storage. Scale lists a typical $701 monthly spend, with rates of $0.222 per CU-hour and the same storage charge. Neither figure is a guaranteed monthly bill, and no annual price is published.

The free tier has firm ceilings: 100 CU-hours monthly per project, 1 GB of storage per project and a maximum of 2 CU. Paid plans still meter several add-ons. Additional branches cost $0.002 per branch-hour; database history is $0.20 per GB-month; snapshots and scheduled backups are $0.09 per GB-month; and object storage is $0.023 per GB-month. Launch and Scale include 500 GB of network transfer per project, then charge $0.10 per GB. Functions have separate capacity-hour and invocation charges. Teams wanting predictable bills will need to estimate compute, storage, transfer and add-on use—not just compare the typical monthly spend.

Neon has a free plan, but its paid prices are typical monthly spends, not fixed subscriptions. The pricing page lists Launch at $15/month typical, with compute at $0.106 per CU-hour and storage at $0.35 per GB-month. Scale is listed at $701/month typical—about 47 times Launch—with compute at $0.222 per CU-hour and the same storage rate. Neither plan has a published annual price.

Free includes 100 projects, 100 CU-hours per month per project, 1 GB storage per project and a limit of 2 CU. Launch allows up to 16 CU; Scale, up to 56 CU. Those ceilings don’t mean the listed typical spend is a bill cap: usage-based charges can move the total.

Budget for extras, too. Launch and Scale charge $0.002 per additional branch-hour, $0.20 per GB-month for database history and $0.09 per GB-month for snapshots and scheduled backups. Object Storage is $0.023 per GB-month. Both plans include 500 GB of network transfer per project, then charge $0.10/GB. Annual billing prices aren’t published.

Moving to Neon means evaluating more than the database. Its offer combines serverless Postgres with authentication, functions, object storage and an AI Gateway. If your app uses those services, inventory them separately before switching: the published material doesn’t document migration tools, export formats or compatibility limits for each one. Functions and storage also have usage-based charges, so map expected use before estimating the new bill.

If you’re moving an existing Postgres app, confirm its schema, extensions and operational needs against Neon’s published docs before planning cutover. The material here doesn’t state which extensions are supported or describe a data-export path, so we can’t promise a simple move in or out. Branching and autoscaling may suit apps with changing database load, but those features don’t remove migration work.

We don’t have sourced Reddit posts or comments in the published material, so we can’t reliably say why users leave Neon. Check current user reports and Neon’s docs for export and support details before committing.