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 scale

ELASTIC 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 developers

PERFORMANCE 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 results

PARTITION 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 partition routing ensures Cosmos DB queries physically access only the relevant tenant partitions. This layered approach strengthens compliance readiness for SOC 2, ISO 27001, GDPR, and enterprise procurement reviews.

• Business units isolate tenants at the platform layer
• Partition routing isolates tenants at the storage layer
• Web roles enforce frontend access permissions
• Defense-in-depth improves compliance readiness

POWER PAGES AS THE FRONTEND EXPERIENCE

Power Pages functions best as the authenticated frontend experience layer rather than the ingestion engine itself. User-facing reads and writes operate through the Web API, while backend services such as Azure Functions or Power Automate handle high-throughput ingestion using CreateMultiple operations. This separation keeps portals responsive while allowing ingestion pipelines to scale independently. Query shaping, pagination, caching, and asynchronous loading patterns become essential for maintaining fast user experiences within Power Pages request limits.

JSON COLUMNS AND FLEXIBLE DATA MODELS

Elastic Tables support JSON-based schema flexibility by allowing semi-structured metadata inside string columns. This enables tenant-specific customizations without requiring constant Dataverse schema changes. Entire activity feeds or operational datasets can be stored as compact JSON payloads instead of thousands of relational rows. The flexibility comes with governance responsibilities. Field-level security does not apply inside JSON structures, meaning sensitive information should always remain in strongly typed Dataverse columns where security policies can be enforced properly.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.