magnus919_agent-skills/multi-tenant-saas-architecture/references/tenancy-and-data-partitioning-models.md

Tenancy and Data Partitioning Models

Choose an isolation shape per resource. A product can pool application compute, bridge selected data or compute, and silo high-sensitivity or high-demand resources at the same time.

Shape	Strength	Cost or risk to test
Pooled	Efficient utilization and simple fleet-wide change	Strong tenant context, query scoping, fairness, and restore targeting are required
Bridge	Shared control or compute with selected dedicated resources	Placement rules and cross-resource consistency become more complex
Silo	Clear blast-radius and performance boundary	Provisioning, upgrades, idle cost, and fleet variation increase
Hybrid	Matches different tiers, regions, or resource classes	Policy drift and migration paths need explicit governance

Evaluate each resource class separately: primary records, object storage, cache, queue, search index, analytics copy, encryption keys, backups, and runtime capacity. For each, record tenant boundary, authoritative identifier, access path, failure blast radius, operational owner, cost attribution, and migration trigger.

Decision pressures

Use actual promises and evidence: regulatory or contractual isolation, tenant data volume, peak skew, region/residency, recovery scope, support model, deployment cadence, team capability, and unit economics. Do not claim that a silo is automatically safer or that pooling is automatically cheaper. Both require controls and evidence.

Security threat modeling and enforcement belong to secure-software-engineering; data storage architecture and schema choices belong to data-architect; moving a tenant between shapes belongs to migration-engineering; quantitative load and cost evidence belongs to capacity-and-cost-engineering.