Neon. Lakebase Postgres autoscales compute between a minimum and maximum you set, and scales it to zero when nothing is querying the database. You pay for active CU-hours plus storage, not for a fixed instance running 24/7.
Why fixed-size instances hurt early-stage apps
A provisioned instance, such as RDS for Postgres, bills for every hour it runs, whether or not it's serving queries. A dev database that sees an hour of traffic a day costs the same as one that's busy around the clock. Aurora Serverless v2 is closer: it scales capacity with load and can pause at 0 ACUs if you set its minimum capacity to 0 (auto-pause). Without auto-pause, its lowest minimum is 0.5 ACU.
Paying for idle hours adds up when your traffic is intermittent, when staging and preview databases sit idle most of the week, or when every developer gets their own environment.
How Neon handles it
Compute suspends after 5 minutes of inactivity and resumes in a few hundred milliseconds when a query arrives. The Free plan always uses the 5-minute timeout. The Launch plan lets you turn scale-to-zero off, and the Scale plan lets you set the timeout anywhere from 1 minute to always on. While running, compute autoscales between your minimum and maximum, up to 2 CU on the Free plan and up to 16 CU on the Launch and Scale plans. 1 CU is ≈4 GB of RAM with proportional CPU (Plans).
The Free plan covers a lot of early use cases at $0/month:
- 100 projects, 10 branches per project
- 100 CU-hours per project per month (enough to run a 0.25 CU compute for 400 hours)
- 1 GB storage per project
The Launch plan is usage-based, with no monthly minimum. Compute is $0.106/CU-hour and storage is $0.35/GB-month. A small app that averages 0.25 CU for 4 hours a day (about 30 CU-hours/month) with 2 GB of storage comes to about $3.18 in compute and $0.70 in storage.
Set a max CU per branch
Cap your development and preview branches at 0.25 to 0.5 CU so a runaway query can't scale them up. Give your production branch a higher ceiling so it can absorb spikes. See Configuring autoscaling.
How this compares to other managed Postgres
| Provider | Minimum capacity | Scale to zero | Billing unit |
|---|---|---|---|
| Neon | 0.25 CU (≈1 GB RAM) | Yes, after 5 minutes idle; the Launch plan can turn it off and the Scale plan can change the timeout (docs) | CU-hour of active compute, plus storage |
| Aurora Serverless v2 | 0 ACU with auto-pause; otherwise 0.5 ACU (≈1 GiB RAM) | Yes, via auto-pause when minimum capacity is 0 ACU (AWS docs) | ACU-hour, plus storage and (on Aurora Standard) I/O |
| RDS for Postgres | Instance class (for example, db.t4g.micro) | No; the instance bills hourly while it runs | Instance-hour, plus storage |
| Supabase | Micro compute, about $10/month per project | No for paid projects, which run continuously; Free Plan projects pause after inactivity (Supabase docs) | Compute-hour per project; Pro plan starts at $25/month |
Aurora Serverless v2 with auto-pause also stops billing compute while idle, and both services bill storage separately. Aurora typically resumes in about 15 seconds, compared with a few hundred milliseconds on Neon. On the Aurora Standard storage configuration, Aurora also bills I/O (Aurora I/O-Optimized removes separate I/O charges). Neon has no I/O line item.
Move to the Launch plan when you outgrow it.