How to Add Dedicated Infrastructure for Your Highest-Value Tenants

The request always comes sooner than expected

Your SaaS product is running smoothly. Tenants are on shared infrastructure. Performance is good. Then your largest customer sends an email:

"We need dedicated database infrastructure. Our security team requires it before we can sign the annual contract."

Or it is not security. It is performance. Their workload has grown to the point where they are noticeably affected by other tenants on the same server. Or it is data residency. They need their database in a specific geographic region that your shared infrastructure does not cover.

The request varies. The underlying need is the same: this tenant needs their own server.

In most architectures, this request triggers a multi-month project. Provision a separate environment, migrate the data, update the connection configuration, test everything, and coordinate the cutover with the customer. Some teams end up running a parallel deployment of the entire application for that one customer.

With a database-per-tenant architecture, the answer is one command.

What shared and dedicated actually mean

On shared infrastructure, multiple tenant databases run on the same physical server. Each tenant has their own database with their own credentials, but they share CPU, memory, and disk with other tenants. This is cost-effective and works well for the majority of tenants.

On dedicated infrastructure, the tenant's database runs on its own virtual machine. Dedicated CPU, dedicated memory, dedicated disk. No other tenant's queries compete for resources. The server can be placed in a specific geographic region. The isolation is physical, not just logical.

The key point: the tenant's database is the same database either way. Same schema, same data, same connection string. The difference is where it runs, not what it contains.

The migration in practice

Promoting a tenant from shared to dedicated is a single CLI command or API call.

Here is what happens behind the scenes:

1. A dedicated VM is provisioned in the requested region. The database engine is installed and configured automatically. This takes approximately 60 to 90 seconds depending on the region.

2. Native replication begins. The tenant's data is replicated from the shared server to the dedicated VM using the database engine's built-in replication protocol. PostgreSQL uses streaming replication. MySQL uses binary log replication. MongoDB uses replica set synchronization. This is not a backup-and-restore. It is live replication, meaning the tenant's application continues running normally on the shared server while data syncs to the dedicated VM.

3. Replication catches up. The dedicated VM receives all existing data and then stays in sync with ongoing writes. The proxy monitors replication lag.

4. Cutover. When replication lag reaches zero, the proxy briefly pauses queries (typically under 2 seconds), switches the routing to point at the dedicated VM, and resumes. The tenant's application experiences a brief pause, not an outage. No queries are lost.

5. Connection strings stay the same. The tenant's application does not change its database connection. The proxy handles the routing transparently. The connection string that pointed to pg.tenantsdb.com:5432/myapp__acme before the migration points to the same address after the migration. The proxy routes it to the dedicated VM instead of the shared server.

The application does not know the migration happened. There is no configuration change, no connection string update, no deployment required.

Choosing a region

Dedicated VMs can be placed in specific geographic regions. This matters for data residency requirements, latency optimization, or simply placing the database closer to the tenant's users.

If the tenant is already on dedicated infrastructure and needs to move to a different region, the same command handles region-to-region migration. The process is identical: provision a new VM in the target region, replicate, cut over.

The migration uses the same native replication process. Zero downtime, connection strings unchanged.

Mixing shared and dedicated in the same project

Not every tenant needs dedicated infrastructure. Most tenants work perfectly well on shared servers. The ability to mix both within the same project, using the same API, the same proxy, and the same schema management, is what makes this practical.

A typical project might look like this:

All four tenants are managed through the same CLI, the same API, and the same proxy. Schema deployments hit all of them in one operation regardless of their isolation level. The operational overhead of having some tenants on dedicated infrastructure is zero.

Per-database promotion

A tenant can have multiple databases across different engines. The promotion to dedicated infrastructure is per-database, not per-tenant. This means you can put the tenant's PostgreSQL on a dedicated VM for performance while keeping their Redis on shared infrastructure where it works fine.

This granularity avoids over-provisioning. You pay for dedicated infrastructure only where it is needed.

Monitoring the migration

Migrations run asynchronously. You can check the status at any time.

The tenant status shows "migrating" during replication and returns to "ready" once the cutover is complete. Queries continue to work normally throughout the process.

If replication encounters an issue, the platform automatically falls back to a safe backup-and-restore approach. A safety backup is always taken before migration begins, so the worst case is a slower migration, never data loss.

Demoting back to shared

The promotion is not permanent. If the tenant no longer needs dedicated infrastructure, they can be moved back to shared.

The same process runs in reverse. Data is replicated from the dedicated VM back to the shared server. Cutover happens with the same brief pause. The dedicated VM is terminated and its resources are released.

This flexibility means you can promote a tenant for a specific period (during a compliance audit, a high-traffic season, or a proof-of-concept) and demote them when the need passes.

What this means for your business

The ability to offer dedicated infrastructure per tenant, per database, with zero downtime and no code changes, is a product feature you can sell.

Pricing flexibility. Dedicated infrastructure costs more to operate, so you charge more for it. The L2 add-on becomes a revenue line item, not just a cost center. Tenants that need it pay for it. Tenants that do not, stay on cost-effective shared infrastructure.

Sales enablement. When a prospect asks "can we get dedicated infrastructure?" the answer is yes, and it takes effect in under 2 minutes. That answer closes deals that would otherwise stall for months while engineering figures out how to deliver it.

Compliance readiness. When an auditor asks about physical isolation, you can demonstrate it for specific tenants without running a separate deployment. The isolation is per-tenant, provable, and reversible.

Operational simplicity. One platform, one API, one set of tools. The fact that some tenants are on shared infrastructure and others are on dedicated VMs is invisible to your application and transparent to your operations team.

Getting started

Every tenant starts on shared infrastructure by default. Promotion to dedicated is available on all paid plans. The free tier supports up to 5 tenants on shared infrastructure.

Full documentation is available at docs.tenantsdb.com/cli#tenants-migrate.

Start free with up to 5 tenants at docs.tenantsdb.com.