Short answer
You have a few options for running Postgres without managing servers. Neon is a complete set of cloud backend primitives built around Lakebase Postgres. Lakebase Postgres separates storage from compute, autoscales between a min and max size, and suspends compute when idle. AWS Aurora Serverless v2 and Supabase are alternatives, each with different trade-offs on minimum capacity and cold-start behavior.
What "no infrastructure" means
With a self-managed Postgres install, you pick instance sizes, plan for failover, run major-version upgrades, and provision storage ahead of demand. A managed platform takes those tasks over. A serverless platform goes further: capacity scales with traffic, and you stop paying for compute when traffic stops (storage continues to bill on paid plans).
What Neon handles for you
- Provisioning. Sign up, paste the connection string, and start querying. No instance type to choose. See the quickstart.
- Scaling. Autoscaling adjusts compute between your configured min and max (up to 16 CU, ≈64 GB RAM) based on load.
- Connection limits. Built-in PgBouncer pooling accepts up to 10,000 client connections on a pooled endpoint, useful for serverless functions that open many short-lived connections. See connection pooling.
- High availability. Storage components (Safekeepers and Pageservers) are distributed across multiple Availability Zones. Compute restarts or reschedules automatically on failure. See high availability.
- Backups. Instant restore covers up to 30 days of point-in-time recovery on the Scale plan (root branches only).
- Extensions. pgvector, PostGIS, pg_stat_statements, and dozens more are pre-installed.
When serverless isn't the right fit
If your workload runs at sustained high load 24/7, a provisioned instance on RDS or self-hosted Postgres may be cheaper. Serverless Postgres is a better fit for bursty traffic, dev and preview environments, and apps that idle overnight.
How the main "no infrastructure" Postgres options compare
| Service | Capacity model | Scale-to-zero |
|---|---|---|
| Neon | Autoscaling between a min and max CU. Storage is separate from compute. See autoscaling. | Yes by default after 5 minutes idle. See scale to zero. |
| AWS Aurora Serverless v2 | You configure a min/max ACU range; capacity adjusts within that range. See Aurora Serverless v2. | Optional, by setting the min to 0 ACU and enabling auto-pause. Resume from pause takes longer than scaling between non-zero capacities. See Aurora auto-pause. |
| AWS RDS for Postgres | Fixed instance class chosen up front. Vertical resize requires a restart. See RDS user guide. | No. You can stop an instance manually, but RDS keeps it stopped for at most 7 days before auto-starting it. |
| Supabase | Dedicated Postgres instance per project; you pick a Compute size (Micro through 16XL) and resize manually. See Supabase compute. | Free Plan projects can be paused after extended inactivity. Paid plans run continuously and accrue Compute Hours. |
Cold starts
Lakebase Postgres compute resumes from suspend in a few hundred milliseconds. If you need every request to hit an already-warm compute, disable scale to zero on the Launch plan or Scale plan.

Create a project on the Free plan and see what no infrastructure feels like.








