Multitenant app with dedicated databases for each tenant on Azure

When building a multitenant application, you have one app that serves many customers (also called tenants). But how do you store each tenant’s data? One common approach is to give each tenant their own dedicated database. Your app stays the same, but the data is isolated. This model gives you better security, easier backups, and more flexibility for customizing features per tenant. It’s also easier to delete a tenant without touching others. In this article, we will explore how the dedicated database per tenant model works with different Azure database services: Azure CosmosDB Azure SQL Database Azure Database for PostgreSQL Neon Serverless Postgres It's helpful to know there are several ways to store data in multitenant applications. Each has trade-offs, and you can read about other architectural approaches. Why Use Dedicated Databases? If you’re building a SaaS platform on Azure, and your tenants range from small to large businesses, the dedicated database model gives you the most flexibility in scaling up, provides the highest isolation, you can easily delete or export a tenant’s data. This approach is useful for: B2B SaaS apps, where each customer wants strong data separation Apps with custom features per tenant Companies needing separate data retention or compliance policies per customer Enterprise customers who may request full control over their data Azure Cosmos DB Azure Cosmos DB is a NoSQL database that supports JSON-like data. Azure Cosmos DB supports several multitenancy models: Shared Database and Shared Container - All tenants use the same database and the same container (collection). Each item in the container includes a tenant ID. Shared Database, Separate Containers - Tenants share the same Cosmos DB database, but each tenant gets a separate container. You can create a dedicated database per tenant and place multiple containers inside it. Useful if tenants have very different workloads, regulatory requirements, or expect enterprise-level SLAs. How it works: You provision throughput Request Units (RUs) at the database level. This throughput is shared across all containers in that database. Each tenant's data is isolated in its own Cosmos DB database. Pros: Great for highly scalable apps and global distribution. Easy to add new tenants without downtime. Cons: More expensive for small tenants due to reserved RU/s. No SQL-like structure if you prefer relational models. Cost: Cosmos DB charges based on provisioned throughput and storage. Even with auto-scaling, costs may be higher than relational databases for low-traffic tenants. Azure SQL Database Azure SQL is a fully managed SQL Server database in the cloud. For small-scale apps, you can use a single database with a shared schema and filter by tenantId. For better separation, assign each tenant a dedicated schema within a shared database. For full isolation and flexibility, create a separate database per tenant, which is ideal for enterprise customers or premium plans. Using Elastic Pools, you can host many databases efficiently, sharing performance resources and saving cost when tenant usage is variable. This model gives you flexibility, strong security, and support for per-tenant scaling and customization. How it works: You can create a new Azure SQL database per tenant. To save cost, you can group databases into an Elastic Pool to share resources like CPU and memory. Pros: Strong isolation per tenant. SQL support is familiar to many developers. Elastic pools save costs if tenants don’t use full resources. Elastic pools provide built-in protections against the Noisy Neighbor problem. Cons: Database creation is slower (30–60 seconds), not ideal for real-time onboarding Cost grows with the number of tenants if not using Elastic Pools wisely Managing updates or schema changes across many databases or schemas can be complex No native auto-scaling like Cosmos DB — you must configure performance manually Cost: Elastic pools are cost-efficient if many tenants have low usage. Otherwise, you pay for each database’s compute and storage. Azure Database for PostgreSQL Azure offers managed PostgreSQL in Single Server, Flexible Server, and Hyperscale modes. You can give each tenant a dedicated schema or even a separate database within the same PostgreSQL server. This allows for per-tenant customizations and easier data management. For maximum isolation, especially in regulated industries or with enterprise customers, you can deploy a separate PostgreSQL server per tenant. PostgreSQL uses a Connection pooling model, which means it creates a separate process for each connection. This works well for a small number of active users, but becomes inefficient when you have many idle or open connections. In multitenant applications that require lots of simultaneous connections,

Apr 24, 2025 - 10:06

Multitenant app with dedicated databases for each tenant on Azure

When building a multitenant application, you have one app that serves many customers (also called tenants). But how do you store each tenant’s data?

One common approach is to give each tenant their own dedicated database. Your app stays the same, but the data is isolated. This model gives you better security, easier backups, and more flexibility for customizing features per tenant. It’s also easier to delete a tenant without touching others. In this article, we will explore how the dedicated database per tenant model works with different Azure database services:

It's helpful to know there are several ways to store data in multitenant applications. Each has trade-offs, and you can read about other architectural approaches.

Why Use Dedicated Databases?

If you’re building a SaaS platform on Azure, and your tenants range from small to large businesses, the dedicated database model gives you the most flexibility in scaling up, provides the highest isolation, you can easily delete or export a tenant’s data.

This approach is useful for:

B2B SaaS apps, where each customer wants strong data separation
Apps with custom features per tenant
Companies needing separate data retention or compliance policies per customer
Enterprise customers who may request full control over their data

Azure Cosmos DB

Azure Cosmos DB is a NoSQL database that supports JSON-like data. Azure Cosmos DB supports several multitenancy models:

Shared Database and Shared Container - All tenants use the same database and the same container (collection). Each item in the container includes a tenant ID.
Shared Database, Separate Containers - Tenants share the same Cosmos DB database, but each tenant gets a separate container.

You can create a dedicated database per tenant and place multiple containers inside it. Useful if tenants have very different workloads, regulatory requirements, or expect enterprise-level SLAs.

How it works:

You provision throughput Request Units (RUs) at the database level.
This throughput is shared across all containers in that database.
Each tenant's data is isolated in its own Cosmos DB database.

Pros:

Great for highly scalable apps and global distribution.
Easy to add new tenants without downtime.

Cons:

More expensive for small tenants due to reserved RU/s.
No SQL-like structure if you prefer relational models.

Cost:

Cosmos DB charges based on provisioned throughput and storage. Even with auto-scaling, costs may be higher than relational databases for low-traffic tenants.

Azure SQL Database

Azure SQL is a fully managed SQL Server database in the cloud. For small-scale apps, you can use a single database with a shared schema and filter by tenantId. For better separation, assign each tenant a dedicated schema within a shared database. For full isolation and flexibility, create a separate database per tenant, which is ideal for enterprise customers or premium plans. Using Elastic Pools, you can host many databases efficiently, sharing performance resources and saving cost when tenant usage is variable. This model gives you flexibility, strong security, and support for per-tenant scaling and customization.

How it works:

You can create a new Azure SQL database per tenant.
To save cost, you can group databases into an Elastic Pool to share resources like CPU and memory.

Pros:

Strong isolation per tenant.
SQL support is familiar to many developers.
Elastic pools save costs if tenants don’t use full resources.
Elastic pools provide built-in protections against the Noisy Neighbor problem.

Cons:

Database creation is slower (30–60 seconds), not ideal for real-time onboarding
Cost grows with the number of tenants if not using Elastic Pools wisely
Managing updates or schema changes across many databases or schemas can be complex
No native auto-scaling like Cosmos DB — you must configure performance manually

Cost:

Elastic pools are cost-efficient if many tenants have low usage. Otherwise, you pay for each database’s compute and storage.

Azure Database for PostgreSQL

Azure offers managed PostgreSQL in Single Server, Flexible Server, and Hyperscale modes. You can give each tenant a dedicated schema or even a separate database within the same PostgreSQL server. This allows for per-tenant customizations and easier data management. For maximum isolation, especially in regulated industries or with enterprise customers, you can deploy a separate PostgreSQL server per tenant.

PostgreSQL uses a Connection pooling **model, which means it creates a separate process for each connection. This works well for a small number of active users, but becomes inefficient when you have **many idle or open connections. In multitenant applications that require lots of simultaneous connections, this can lead to high memory usage and reduced performance on the server.

How it works:

You can create separate databases inside a single PostgreSQL server for each tenant.
Or use separate PostgreSQL servers for stronger isolation.

Pros:

Mature relational database with many extensions.
Hyperscale (Citus) option available for large-scale, shared-schema workloads.
Flexible schema versioning and backup strategies.
Shared infrastructure (one server) is more cost-efficient for many small tenants.

Cons:

Managing thousands of schemas or databases on a single server can get complex.
Server provisioning still takes time (30+ seconds).
PostgreSQL Flexible Server has some limitations in autoscaling and zone redundancy.

Cost:

You can start cheap, but costs rise with more tenants unless databases are well-packed inside shared servers.

Neon Serverless Postgres

Neon is a serverless Postgres solution on Azure that separates storage and compute. It’s optimized for modern cloud apps and has great branching and autoscaling features. This makes Neon a great fit for multitenant SaaS applications, especially those using the dedicated database per tenant model.

Neon’s serverless architecture solves one of PostgreSQL’s classic limitations — maintaining lots of idle connections. In Neon, compute is paused when not needed, and each database only spins up when accessed. This makes it much more efficient than traditional PostgreSQL or Azure SQL when serving thousands of tenants. You can also define custom connection strings and roles per tenant, store tenant metadata in a central management layer, and manage your multitenant app fully through automation. Read more about the Database Per Tenant approach in Neon.

How it works:

In Neon, a "project" is the top-level unit that contains one or more branches, databases, and roles. In the database-per-user multitenancy model, each tenant is assigned their own Neon project — this is called the project-per-user pattern.

This approach ensures full isolation between tenants:

Each project has its own compute and storage.
You can assign separate roles, passwords, and access controls per tenant.
Each project supports branching, allowing you to create feature branches or test environments per tenant.
Projects can be created instantly using the Neon Management API.

Pros:

Instant database provisioning (< 1 sec)
Scales to zero = excellent cost efficiency
Supports modern CI/CD via branching (great for testing features per tenant)
Ideal for micro-SaaS or large SaaS with flexible pricing tiers
No need to manage infrastructure — serverless by design

Cons:

Newer product, still growing in features.
Not yet available in all Azure regions (but can connect easily from other Azure services)

Cost:

Much lower than Azure SQL or Cosmos DB for big or active tenants. Ideal for micro-SaaS or apps with many free-tier users.

Comparing Key Factors

Feature	Azure SQL	Cosmos DB	PostgreSQL (Azure)	Neon
Type	Relational	NoSQL (JSON)	Relational	Relational
Provision Speed	~30–60 sec	~5–10 sec	~30–60 sec	less than < 1 sec
Cost for Small Tenants	Moderate (elastic pool)	High (RU reservation)	Moderate (shared server)	Low (pay-per-use)
Customization per tenant	High	Medium	High	Low
Scaling	Manual or pool-based	Auto-scaling	Manual	Auto-scaling, serverless

Multitenancy Considerations in RAG Applications

When building AI apps using Retrieval-Augmented Generation (RAG), multitenancy becomes even more important. RAG apps pull in private data from each user or company to improve answers. This means your database setup must keep each tenant’s data fully separate, and also make sure one tenant can’t slow things down for others. This is called avoiding the “noisy neighbor” problem. With Neon, you can give each tenant their own database project, so their data and AI workflows are completely isolated. This makes it easier to manage performance, scaling, and costs for each tenant. If you want to go deeper, Neon explains the setup clearly in this guide: Multi-Tenant RAG With One Neon Project Per User.

Final Thoughts

Choosing dedicated databases per tenant is a solid approach for SaaS builders who need customization, security, and flexibility. Azure gives you many tools to do this — from Cosmos DB and Azure SQL to more modern options like Neon.

If you need fast provisioning, cost-efficiency, and serverless behavior, Neon is a great choice. For classic relational workloads, Azure SQL or PostgreSQL is reliable and well-integrated with other Azure services.

Whatever you choose, Azure has the flexibility to support your multitenant SaaS app at every stage.