Neon organizes databases into projects. A project usually maps to one app or one customer, and each project has its own branches, computes, and storage. You manage every project in your organizations from one account, through the Neon Console, the Neon CLI, or the API. The Free plan includes 100 projects.

How the hierarchy works

Organization (billing, members)
└── Project (e.g. "checkout-api"; region is fixed per project)
    └── Branches (production, staging, preview/pr-1234, ...)
        └── Lakebase Postgres
            ├── Computes (read-write compute, read replicas)
            ├── Databases
            └── Roles

Branches inside a project share storage through copy-on-write, so creating a staging or preview/* branch doesn't copy data or add storage until it diverges. Projects are fully isolated from each other, with separate data, credentials, and connection strings. See the Neon object model.

Project limits by plan

PlanProjects
Free plan100
Launch plan100
Scale plan1,000 (can be increased on request)

On the Free plan, each project gets 1 GB of storage and 100 CU-hours of compute per month (plans).

Managing many projects from the CLI

# List the projects you can access
neon projects list

# Create a project for a new customer
neon projects create --name acme-corp --region-id aws-us-east-1

# Get the connection string for that project's default branch
neon connection-string --project-id quiet-frost-12345

For programmatic provisioning, such as a new database for each customer who signs up, use the API or the Neon TypeScript SDK.

Organizations and access control

Every project lives in an organization. Each member gets an organization role (Admin, Editor, Viewer, or Collaborator) that sets their baseline access across all projects, and you can grant per-project permissions on top of it. To limit someone to specific projects, give them the Collaborator role and grant access only to those projects. Every plan includes unlimited organization members.

One project per customer

If you're building a B2B app and need hard data isolation between customers, create a project per customer. Data, credentials, and settings like the history window and IP Allow rules are scoped to the project, and the API makes provisioning scriptable. See Multitenancy.

How other Postgres services handle multiple databases

  • Supabase: Each project is a dedicated Postgres instance on its own server, and you're charged for that server's compute whether or not the database is in use (billing on Supabase). On paid plans, each additional project adds at least the Micro compute cost (~$10/month) (compute usage). The Free Plan allows two free projects, counted across every organization where you're an Owner or Administrator (same billing page).
  • AWS RDS for Postgres: Each DB instance has its own instance hours and storage. There's no project abstraction, so teams organize instances with tags, accounts, or VPCs. You can script provisioning with the AWS CLI or CloudFormation (RDS getting started).
  • AWS Aurora Serverless v2: Same model as RDS, with compute that scales in ACUs. Each cluster bills separately, and you manage clusters through the AWS Console, CLI, or API (Aurora Serverless v2).

For database-per-tenant setups on Neon, idle projects scale to zero, so a tenant that isn't active stops accruing compute charges. Storage still bills on paid plans, and each Free plan project includes up to 1 GB.

Manage projects in one place

Sign up and see how 100 free projects fit on one account.