Separate Database

Introduction

Multi-Tenant Separate Database provisions each tenant (or tenant tier) with its own database instance or cluster — maximum isolation, highest cost and operational complexity. LinkedIn Talent Solutions offers dedicated database tiers for enterprise recruiting customers whose contracts mandate physical separation, custom backup RPO/RTO, and regional data residency.

Real production story

LinkedIn's recruiting platform initially ran all customers on shared PostgreSQL with tenant_id — workable for SMB customers. A Fortune 50 bank signed a $12M deal requiring dedicated infrastructure: separate RDS in eu-west-1, customer-managed encryption keys, and independent backup schedule. A previous noisy-neighbor incident on shared infrastructure (another customer's analytics query caused 8-second p99 for the bank's recruiters) nearly killed the deal.

Staff architects built a database provisioning pipeline: enterprise contract signed → Terraform creates dedicated RDS + read replica + backup policy → tenant router maps customer_id to connection string from Vault. SMB customers remain on shared database tier. Enterprise tier pays 4× base price — funding dedicated ops. Zero cross-tenant incidents on dedicated tier since launch.

Business problem

Business pressure: LinkedIn enterprise deals require physical isolation, regional residency, and independent failure domains — shared database fails enterprise procurement checklists regardless of application-level filters.

• Revenue at risk: Fortune 500 recruiting contracts ($5M–$20M) mandate dedicated infrastructure — without it, deals lost to competitors.
• Engineering velocity: N databases means N migration fleets — platform team must automate or drown.
• Compliance / trust: SOC2, GDPR, and customer audit require "show me my database" — separate database is the answer.

Architecture overview

Separate Database in production: each enterprise tenant gets dedicated database server/cluster (RDS, Cloud SQL, etc.) with own credentials, backup policy, and migration history. Application routes via tenant-aware connection resolver — never shared connection pool across tenants.

• Definition: Physical database isolation per tenant or tenant tier — separate storage, compute, and failure domain.
• When to adopt: Enterprise contracts, regulatory mandates, extreme noisy-neighbor sensitivity, customer-managed keys.
• When to defer: SMB/mass market with millions of tenants — economics break without extreme pricing.
• Operability: Infrastructure-as-code provisioning; centralized migration runner against fleet; per-DB monitoring dashboards.

Architecture motivation

Why architects care: Separate database is the strongest isolation tier — choose for regulatory, contractual, or noisy-neighbor requirements that shared models cannot satisfy. Cost and ops complexity are the price.

• Force: Contractual physical isolation; data residency; independent backup/restore SLA.
• Constraint: Cannot manually provision and migrate thousands of databases — automation mandatory.
• Outcome: Tiered offering: shared DB for SMB, separate DB for enterprise; automated provisioning pipeline.

Internal architecture

LinkedIn Talent Solutions tiered database topology:

                    ┌─────────────────────┐
                    │   Tenant Router     │
                    │ (customer_id → DSN) │
                    └──────────┬──────────┘
           ┌───────────────────┼───────────────────┐
           ↓                   ↓                   ↓
   Shared RDS Pool      Enterprise RDS (EU)   Enterprise RDS (US)
   (SMB customers)      (Fortune 50 bank)     (Healthcare corp)
   tenant_id rows       dedicated instance     dedicated instance
   eu-west-1 multi      eu-west-1 only         us-east-1 only

Data flow

Enterprise request path: JWT contains customer_id → router lookup in config service → Vault returns DSN → dedicated connection pool for that customer only → query runs on isolated RDS.

• Write path: no tenant_id column required on every table — isolation is infrastructure-level (still recommended for defense in depth).
• Read path: read replica per enterprise customer for analytics isolation from OLTP.
• Async path: backup and PITR per database — restore one customer without affecting fleet.

class TenantDatabaseRouter {
  private cache = new Map<string, Pool>();

  async getPool(customerId: string): Promise<Pool> {
    if (this.cache.has(customerId)) return this.cache.get(customerId)!;
    const tier = await config.getTier(customerId);
    if (tier === "shared") return this.sharedPool;
    const dsn = await vault.read(`database/${customerId}/dsn`);
    const pool = new Pool({ connectionString: dsn, max: 20 });
    this.cache.set(customerId, pool);
    return pool;
  }
}

// Provisioning: contract webhook → Terraform Cloud workspace
async function provisionEnterpriseDb(customerId: string, region: string) {
  await terraform.apply("modules/enterprise_rds", { customerId, region });
  await migrationRunner.bootstrap(customerId);
  await config.setTier(customerId, "dedicated");
}

System design diagram

Two diagrams show the Separate Database topology and the primary request/event path used in production at scale.

Production code example

Enterprise DB provisioning module with migration bootstrap:

# modules/enterprise_rds/main.tf
resource "aws_db_instance" "tenant" {
  identifier     = "linkedin-talent-${var.customer_id}"
  engine         = "postgres"
  instance_class = var.tier == "large" ? "db.r6g.2xlarge" : "db.r6g.xlarge"
  allocated_storage = var.storage_gb
  kms_key_id     = var.customer_kms_arn
  backup_retention_period = var.contract_rpo_days
  multi_az       = true
  tags = { Customer = var.customer_id, Tier = "enterprise" }
}

output "dsn" {
  value     = "postgresql://${var.app_user}@${aws_db_instance.tenant.address}/talent"
  sensitive = true
}

Enterprise case study

LinkedIn Talent Solutions enterprise tier: 240 dedicated RDS instances across 4 regions; Terraform provisioning in 12 minutes; migration runner with canary fleet.

• Before: Fortune 50 deal at risk after noisy-neighbor SLA breach on shared tier.
• Decision: Tiered model with automated dedicated DB provisioning; 4× price premium for enterprise isolation.
• After: $180M enterprise pipeline closed in 18 months; zero isolation incidents on dedicated tier.

Trade-offs

• Isolation vs cost: Strongest isolation — 3–5× infra cost per tenant; must price into enterprise tier.
• Ops automation vs manual toil: Without IaC provisioning, ops team drowns at 50+ enterprise customers.
• Migration fleet vs velocity: Schema change runs N times — parallelize with canary on 3 DBs first.

Security considerations

Security is architectural: Separate database enables customer-managed KMS keys, VPC peering, and audit scope limited to one customer's instance.

• Identity: unique DB credentials per customer stored in Vault; rotated quarterly.
• Data: encryption at rest with customer-managed key; cross-region replication disabled unless contract allows.
• Supply chain: RDS parameter groups hardened per tier; CIS benchmark automated scan on provision.

Scalability analysis

Scale dimensions: LinkedIn targets hundreds of enterprise dedicated DBs, not millions — tier boundaries and automation determine viability.

• Horizontal scale: each DB scales independently; router adds negligible overhead.
• Hot spots: one enterprise customer's seasonal hiring spike isolated — no noisy neighbor to others.
• Cost: chargeback model: enterprise tier covers RDS + replica + backup + ops FTE allocation.

Failure scenarios

What breaks: Terraform provision fails leaving customer in limbo; migration runner fails on 3/200 DBs; router cache serves stale DSN after DB migration.

• Partial fleet migration: per-DB migration status; block feature launch until 100% or explicit exception documented.
• Stale DSN cache: TTL on pool cache; invalidate on config change event.
• Provision failure: saga: rollback Terraform, notify sales, never partial tier assignment.

Staff engineer insights

• Separate database is a product tier, not an architecture default — price it or go broke on RDS bills.
• Automate provisioning before sales promises dedicated infrastructure — manual RDS creation kills deal velocity.
• Migration runner with canary fleet (3 DBs) prevents fleet-wide schema failure.

Interview questions

Architecture review questions

• Are quality attributes (latency, availability, consistency) explicit with SLOs for Multi-Tenant Separate Database?
• Is the failure/degraded mode documented — including what happens when dependencies are down?
• Are boundaries and ownership clear on an architecture diagram a new engineer understands in 10 minutes?
• Is there an ADR capturing alternatives considered and why they were rejected?
• Can this design scale 10× on traffic and 3× on engineering headcount without a rewrite?
• Security: authn/authz, encryption, and blast radius reviewed at every external interface?

Summary

Multi-Tenant Separate Database at LinkedIn scale is an enterprise product tier — dedicated RDS per customer with IaC provisioning, Vault-managed DSNs, and fleet migration discipline. Automate before sales promises, price for ops cost, and keep SMB on shared tier for economics.