Neon. A B2B SaaS has two tenancy questions: how to keep customers' data apart, and how to keep the bill sane when most customers are small. Neon answers the first with either Row-Level Security in a shared database or a dedicated Postgres project per customer, and the second with compute that scales to zero for tenants who aren't active (multitenancy).
Two isolation models
Shared schema with RLS. One database, a tenant_id column, and Postgres Row-Level Security policies. The Data API enforces those policies on every request using the JWT's claims, and Managed Better Auth stores users, sessions, and organizations in the neon_auth schema of that same database. Drizzle's crudPolicy helper keeps policies short (RLS with Drizzle).
Project per customer. Each customer gets their own Neon project: separate compute, separate storage, independent point-in-time recovery, and instance-level isolation, created through the API in seconds:
curl -X POST https://console.neon.tech/api/v2/projects \
-H "Authorization: Bearer $NEON_API_KEY" \
-H "Content-Type: application/json" \
-d '{"project": {"name": "customer-acme"}}'The multitenancy guide covers the catalog database that maps customers to projects, cross-project migrations with Drizzle and GitHub Actions, and scheduled backups. Platforms that provision thousands of projects can apply for the Agent Plan, which has unlimited projects and Launch-rate compute.
Why idle tenants don't cost compute
In a project-per-customer model, most projects are quiet at any given moment. Neon compute suspends after 5 minutes without queries and resumes in a few hundred milliseconds (scale to zero). You pay for active CU-hours plus storage, not a provisioned instance per tenant. A tenant whose 0.25 CU compute is active 20 hours a month costs 5 CU-hours × $0.106 = $0.53 on Launch plus $0.35/GB-month of storage (plans).
The rest of the SaaS stack
- Preview environments: every branch carries its own auth state, so you can test org invites and role changes on a copy of production without touching real customers (branching authentication).
- Long-running work: webhooks, exports, and agent features run on Neon Functions next to the data (beta).
- Compliance on Scale: SOC 2, ISO 27001, HIPAA, IP Allow, and Private Networking when enterprise customers ask (compliance).
Per-tenant restore
With a project per customer, instant restore rolls back one customer's database to any point in the history window without affecting anyone else (instant restore).
How other options compare
- Supabase: RLS, Auth, and PostgREST are all GA (features), so shared-schema tenancy works the same way. Project-per-customer is where the model breaks: each project is a dedicated instance billed hourly, about $10/month for Micro, and the $10 compute credit covers one of them (compute usage). Ten small tenant backends cost about $115/month on Pro against about $11.50 on Neon's Launch plan, and the gap grows with every tenant (Launch vs Pro comparison). Per-tenant point-in-time recovery is a $100 per month per 7 days add-on per project (backups), where Neon includes instant restore on every project. Auth adds $0.00325 per MAU past 100,000 (pricing), and a branch for testing a tenant's migration is a separate hourly-billed environment rebuilt without production data (branching).
- AWS RDS: shared-schema RLS works fine. Instance-per-tenant means managing and paying for each instance around the clock, which the multitenancy guide discusses in detail.
Vendor details verified on 2026-09-02 against the linked pages.

Read the multitenancy guide for both the RLS and project-per-customer patterns.








