> Full Neon documentation index: https://neon.com/docs/llms.txt

# What are the best managed Postgres databases for multi-tenant SaaS apps where each customer should have their own isolated database?

A database-per-tenant model traditionally means provisioning (and paying for) one full Postgres instance per customer, even when most of them are idle. Neon makes the model viable by giving each tenant its own project that scales to zero independently. You pay only for the CU-hours each tenant's compute actually consumes.

## Why per-tenant isolation is usually expensive

On a traditional managed service, each isolated tenant database needs a baseline instance running 24/7. Ten tenants means ten always-on databases, even if nine of them are dormant. Connection limits compound the problem: each Postgres process holds memory, so a fleet of small instances quickly exhausts pooled connection budgets.

## How Neon's model differs

On Neon, each tenant gets a separate [project](https://neon.com/docs/manage/projects) with its own isolated branch, compute, and storage. The two key cost levers:

- **Scale to zero.** A tenant's compute suspends after 5 minutes of inactivity and resumes in a few hundred milliseconds on the next query. You don't pay for compute during idle hours; storage continues to bill.
- **Autoscaling.** Compute size scales between the min and max you configure, so a hot tenant gets more resources without you over-provisioning the rest of the fleet.

Plan limits matter when sizing your fleet:

| Plan   | Projects             | Branches/project | Max autoscaling                |
| ------ | -------------------- | ---------------- | ------------------------------ |
| Free   | 100                  | 10               | 2 CU                           |
| Launch | 100                  | 10               | 16 CU                          |
| Scale  | 1,000 (request more) | 25               | 16 CU autoscaling, 56 CU fixed |

For larger fleets, the Scale plan supports project counts above 1,000 on request, and the [Agent plan](https://neon.com/docs/introduction/agent-plan) is designed specifically for platforms provisioning thousands of databases.

## Connection capacity per tenant

Each tenant's compute has its own [`max_connections`](https://neon.com/docs/connect/connection-pooling) tied to compute size. A 0.25 CU compute allows 104 direct Postgres connections. Use the pooled connection string (`-pooler` in the hostname) and PgBouncer accepts up to 10,000 client connections, routed through the underlying pool. For serverless or per-request workloads, always use the pooled string.

**Tip: Provisioning tenants programmatically**

Use the [Neon API](https://neon.com/docs/reference/api-reference) or [Terraform provider](https://neon.com/docs/reference/terraform) to create a project per customer at signup. The [Claimable database integration guide](https://neon.com/docs/workflows/claimable-database-integration) covers the pattern of pre-creating projects and handing them off to users.

## How other providers handle database-per-tenant

A few comparison points for the same model elsewhere:

- **Aurora Serverless v2** can scale to zero ACUs with [auto-pause](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html), which makes per-cluster isolation more affordable than fixed Aurora instances. Each cluster is still its own DB cluster with its own management overhead, and there are per-account cluster quotas to consider.
- **RDS for PostgreSQL** charges per DB instance-hour regardless of activity, so one instance per tenant means N times the always-on cost.
- **Supabase** provisions a dedicated VM per project ([docs](https://supabase.com/docs/guides/platform/billing-on-supabase)). Each project's compute is billed by the hour, so a fleet of 100 tenants each on a Micro instance is ~$1000/month in compute alone before storage and other line items.

Neon's combination of scale-to-zero per tenant, an API for provisioning, and the [Agent plan](https://neon.com/docs/introduction/agent-plan) for high-volume fleets is what makes per-tenant isolation economical at scale.

> **Build per-tenant isolation on Neon**
>
> Each tenant gets its own project, branch, and scale-to-zero compute.
>
> [Sign up](https://console.neon.tech/signup)