[object Object]

Elastic tables are Dataverse’s NoSQL option, backed by Azure Cosmos DB. They went GA, then quiet, and are now the right answer for a specific class of workload: high-write, schema-flexible, low-relationship. Most teams either over-use them or do not know they exist.

What makes a table elastic

When you create a table in Power Apps, you pick the storage tier. Elastic tables use Cosmos DB partition keys, support schema-less attributes via the JsonAttribute, and scale write throughput far beyond standard tables. Read patterns are key-based; relational queries are limited.

When elastic wins

  • IoT telemetry summaries, product event logs, audit-style records.
  • Tables expecting more than 100M rows.
  • Tables with sustained write rates above 100 writes/second.
  • Workloads with semi-structured payloads where columns vary per record (event types, custom JSON).

When elastic loses

  • Records that need joins to other tables in views or reports.
  • Records that need to participate in plugins, BPFs, or workflows (limited support).
  • Anything that needs FetchXML aggregations across joined entities.
  • Records with security-role read filters more granular than Owner.

The partition key decision

Every elastic table requires a partition key chosen at creation. The key drives where rows physically live. Choose well and queries on that key are sub-millisecond. Choose poorly and you have hot partitions that throttle.

Good partition key: tenantId, customerId, deviceId (high cardinality, evenly distributed).

Bad partition key: status code, country, year (low cardinality, hot partitions).

TTL is built in

Elastic tables support time-to-live: a per-row TTL field that auto-expires the record. This is the killer feature for log-style data. No more Bulk Delete jobs.

Power Apps -> Tables -> [elastic table] -> Properties 
-> Time to live: enabled -> Default TTL: 90 days

API differences

Standard Web API operations work. FetchXML works for filters on the partition key. Cross-partition queries are slower and may need explicit cross-partition flag. Plugin context exposes elastic tables but with reduced metadata.

GET /api/data/v9.2/elastictable?$filter=customerid eq 'abc' 
&PartitionId='tenant-1234'

Cost model

Elastic tables consume Cosmos DB request units (RUs), provisioned per environment. Microsoft includes a baseline; high-throughput workloads need add-on RU capacity. Model your write rate against the included RUs before launch.

Real use cases that work

  • Storing per-page view events from a web app.
  • Storing per-message SMS delivery records.
  • Storing per-device heartbeats from connected products.
  • Storing per-call transcription chunks for service interactions.

What to do this week

Find the largest standard table in your environment by row count. If it is over 50M rows, has predictable write patterns, and is rarely joined to other tables, it is a candidate for migration to elastic. Plan a parallel write before cutover.

[object Object]
Share