Breaking the Scale Barrier: Building Multi-Tenant SaaS on Power Pages

Building multi-tenant SaaS on Power Pages changes the way architects think about Dataverse scalability. Most developers traditionally viewed Power Pages as a portal platform intended for forms, authentication, and moderate business applications. Enterprise-scale SaaS workloads were assumed to require fully custom Azure infrastructure and external databases. Elastic Tables challenge that assumption by introducing Cosmos DB-backed storage directly inside Dataverse, allowing Power Pages to support large-scale operational workloads while preserving the familiar Dataverse developer experience.

WHY STANDARD DATAVERSE TABLES HIT LIMITS

Standard Dataverse tables are optimized for relational transactional workloads such as CRM systems, account management, and business processes. They perform extremely well for structured business entities but begin struggling under workloads dominated by telemetry ingestion, event logging, audit history, and append-heavy operational data. As tenant counts grow, noisy-neighbor effects appear because all tenants compete for the same relational backend resources. The architecture problems become especially visible when SaaS platforms start accumulating massive volumes of operational records. Bulk write operations slow down, storage costs increase rapidly, and query performance degrades under high-ingestion scenarios. These are not flaws in Dataverse itself but rather signs that the workload no longer aligns with the strengths of Azure SQL-backed storage.
• Azure SQL excels at relational workloads
• Operational SaaS data behaves differently
• Multi-tenant contention creates performance issues
• Storage costs rise quickly at scaleELASTIC TABLES AND COSMOS DB

Elastic Tables replace the underlying SQL engine with Azure Cosmos DB while preserving the same Dataverse APIs, security model, and Power Pages integration patterns developers already know. From the outside, the experience still feels like standard Dataverse development. Underneath, however, the storage model becomes horizontally scalable and partition-aware. Cosmos DB distributes records across logical partitions using PartitionId values. This enables Elastic Tables to scale write throughput horizontally rather than relying on a single database instance. Microsoft specifically designed Elastic Tables for telemetry, event streams, operational logging, and large append-heavy workloads that traditionally break relational systems at scale.
• Horizontal partitioning improves scalability
• Bulk ingestion becomes dramatically faster
• TTL support enables automatic data expiration
• Dataverse APIs remain unchanged for developersPERFORMANCE DIFFERENCES THAT MATTER

Elastic Tables dramatically outperform standard tables during batch operations such as CreateMultiple and UpdateMultiple requests. Community benchmarks showed improvements ranging between two and ten times faster for bulk ingestion scenarios. This advantage exists because Cosmos DB distributes writes across partitions simultaneously rather than funneling all operations through a single relational engine. At the same time, Elastic Tables are not universally superior. Standard relational queries and traditional CRUD operations may still perform better on SQL-backed Dataverse tables. Successful SaaS architectures therefore separate operational workloads from relational business entities rather than attempting to move everything into Elastic storage.
• Elastic Tables dominate high-volume writes
• Standard tables remain stronger for relational queries
• Batch ingestion benefits most from Cosmos DB
• Hybrid architectures deliver the best resultsPARTITION STRATEGY DEFINES SUCCESS

Partition design is the single most important Elastic Table decision because the partition key cannot be changed after deployment without migration. For multi-tenant SaaS platforms, tenantId naturally becomes the foundation of the partition model because nearly every query is scoped to a tenant context. Large enterprise customers introduce additional complexity. A single “elephant tenant” can overwhelm a partition if all records share the same partition key. Hierarchical Partition Keys solve this by introducing multiple partition levels such as tenantId, userId, and sessionId. This spreads traffic and storage evenly while preserving efficient query routing. The resulting architecture supports both small tenants and extremely large enterprise customers without requiring different application logic or separate development patterns. 

SECURITY AND TENANT ISOLATION

Security in multi-tenant SaaS depends on structural isolation rather than trusting developers to consistently apply tenant filters. The architecture combines Dataverse business units, web roles, table permissions, and partition-aware query routing to create layered tenant isolation across both the platform and storage layers. Business units define tenant boundaries inside Dataverse, while tenantId-based par...