Data Isolation at Scale

Why database-per-user?

One of the first design decisions you’ll face when building an application with Postgres is how to organize your multitenancy. For certain use cases, adopting a database-per-tenant approach is the most beneficial:

• Meet strict data privacy requirements - If you’re operating a B2B SaaS platform with customers in regulated industries, they may require maximum data isolation at the instance level. A database-per-tenant approach allows you to meet these stringent data privacy demands by offering each customer their own isolated database.
• Comply with regional data regulations - In cases where data regulations require customer data to be stored within specific regions, creating separate databases in each region provides a straightforward path to compliance.
• Simplify management - If your customers require isolated workflows like backups, PITR, or migrations, database-per-tenant makes these easier to manage without cross-tenant risk.
• Avoiding noisy neighbors - When customers share an instance, a spike in usage from one tenant can degrade performance for others. Isolating tenants ensures consistent performance.

Scaling database-per-user architectures in AWS is not a good idea

Managed Postgres services like Amazon RDS weren’t designed for high-volume, database-per-tenant use cases. While you can technically isolate each customer with their own database, doing so at scale becomes operationally and financially unsustainable. There are two common paths teams take—both with major drawbacks:

1. Cramming thousands of databases into a single RDS instance

Many teams try to save money by putting all their tenants into one large RDS instance. But this leads to:

• Single point of failure - If that instance goes down, all of your customers are impacted.
• Noisy neighbors - Resource-hungry tenants can degrade performance for others sharing the same compute.
• Complex maintenance - Backups, PITR, monitoring, and upgrades become harder to manage when they're tied to a massive shared instance.
• Rigid scaling - You can’t scale individual tenants—you have to scale the entire instance, often overpaying for idle capacity.

2. Spinning up one RDS instance per tenant

This approach gives you the isolation you’re looking for, but it comes at a steep cost—both in dollars and engineering time. The truth is, RDS was never designed for this kind of architecture:

• Expensive and wasteful - Each RDS instance has a baseline cost, even when idle. Multiply that across hundreds or thousands of tenants, and your bill quickly becomes unsustainable. Storage also doesn’t scale down: once it grows, you’re stuck paying for it.
• No dynamic scaling - RDS instances don’t autoscale. Resizing compute often requires manual intervention—and in many cases, downtime.
• High operational burden - You’ll soon need a dedicated team just to handle instance provisioning, monitoring, patching, and scaling logistics. Even basic tasks become complex at scale.
• Slow setups - Spinning up a new RDS instance can take minutes, not seconds—far from ideal from the end-user experience.

Our customers require their data to live in an isolated database, but implementing this in RDS was cumbersome and expensive

Postgres the way multi-tenant SaaS was meant to work

Neon reimagines Postgres for modern SaaS. With serverless infrastructure, autoscaling, and scale-to-zero, Neon eliminates the overhead that typically makes database-per-tenant architectures so hard to manage. Each customer lives in their own isolated project, and everything—from provisioning to recovery—is API-driven. You get true instance-level isolation without the cost or complexity of managing thousands of traditional Postgres instances.

One project per customer

A Neon project is the logical equivalent of an "instance", but without the operational heaviness.

• Each customer's data is completely isolated
• You can run independent PITRs for a single tenant without affecting your entire fleet
• You can deploy projects in specific regions to meet local compliance requirements
• You avoid noisy neighbors entirely—no resource contention between tenants

Scale each tenant independently

In RDS, you’d have to choose an instance size and disk allocation up front—and scale manually as usage changes. With Neon, compute autoscales on demand, and storage grows and shrinks automatically. You don’t need to provision compute or storage in advance. Every tenant gets their own resources, and those resources scale automatically based on usage. No manual resizing, no idle waste.

• No more over-provisioning - Your busiest customers get more power when they need it. Everyone else runs lean—or not at all.
• Scale to zero when idle - If a tenant isn’t using their database, Neon pauses compute and you pay nothing until they return.
• Fine-grained control - Set compute limits, quotas, and performance policies per tenant to match their plan or use case.

Rollback a single customer in seconds

In most managed Postgres services like RDS, restoring a database is a slow, manual process. It typically involves spinning up a new instance from a snapshot, waiting several minutes (or longer), and restoring all databases that lived inside that instance—whether or not they were affected.

Neon takes a completely different approach. Thanks to our copy-on-write storage engine, Neon lets you restore databases to any previous moment instantly—with no downtime, no data duplication, and no need to preconfigure backups.

• You can restore just one customer’s database (project) to any point in time—within seconds.
• You don’t affect other tenants, because recovery operations are fully isolated.
• You don’t have to spin up new infrastructure—recovery happens in place, with zero operational overhead.

This is especially valuable in B2B SaaS platforms, where customers may request a rollback to a specific date due to data errors, user mistakes, or compliance requirements. With Neon, you can fulfill these requests in seconds—without escalation, without disruption, and without touching the rest of your fleet.

API-first management

Neon was built to help you manage thousands of Postgres databases like they’re one. Every operation—provisioning, configuring, scaling, restoring, deleting—is available via our public API. This enables you to fully automate your database lifecycle and manage a massive tenant fleet with minimal engineering effort.

• Provision at scale - Create new databases for customers programmatically, in milliseconds, with no infrastructure to manage or pre-allocate.
• Track usage and enforce limits - Set per-project quotas for storage, compute, and active time to align with your pricing tiers or customer plans.
• Control costs at the tenant level - Monitor usage and apply automated limits or alerts before tenants exceed plan thresholds.
• Billing aligned to actual usage - Neon’s pricing is based on consumption—not provisioned capacity—so you only pay for what each tenant uses.
• One engineer can manage thousands of tenants - With the right automation in place, there's no need for a large DevOps team.

Data compliance and security

When you're building a multi-tenant SaaS platform—especially in regulated industries—data privacy and compliance aren’t optional. With Neon, instance-level isolation is built into the architecture, making it easier to meet the strictest customer and regulatory requirements.

• True data isolation - Each customer lives in their own Neon project, with completely separate compute and storage. There's no risk of cross-tenant data access or resource contention.
• Regional project placement - Deploy tenant data in specific geographic regions to meet data residency requirements like GDPR, HIPAA, or industry-specific regulations.
• Access control at the project level - Assign unique credentials and connection strings per tenant, and manage access on a per-project basis.
• Audit-friendly recovery workflows - Instant, per-tenant PITR enables precise rollback to any point in time—helping you meet data retention and recovery SLAs.
• Enterprise-level security - All Neon projects use TLS for connections, and built-in encryption is applied to data at rest and in transit.

Development environments

To take advantage of database branching workflows for dev/test whithin a project-per-tenant design, create a separate Neon project as your single non-prod environment. The methodology:

• Load your testing data to the main branch. This main branch acts as the primary source for all dev/test environments (they can be hundreds).
• To instantly create ephemeral environments, derive child branches from the main branch. These branches are fully isolated resource-wise and already include an up-to-date copy of the testing dataset. They can then be synced with the main branch with just one click.
• Once the work is complete, ephemeral dev/test environments (child branches) can be deleted automatically via your CI/CD.