Elastic tables in Dataverse

For most Dataverse use, the answer is "use a standard table." But for scenarios with very high write throughput, very large row counts, or schema flexibility needs, elastic tables offer a different storage backend with different trade-offs. Knowing when each fits is part of being effective in Dataverse architecture.

Standard tables. Backed by Azure SQL Database. The properties:

• Strong relational integrity.
• Full FetchXML and OData query support.
• Sophisticated workflow, plugin, business rule extensibility.
• Throughput limits in the hundreds to low thousands of writes per second per table.
• Sized in the millions of rows comfortably; tens of millions with care; hundreds of millions slows down.

This is the default and the right answer for ~95% of business data.

Elastic tables. Backed by Azure Cosmos DB (NoSQL document store) underneath the Dataverse abstraction. The properties:

• Massive write throughput (tens of thousands of writes per second).
• Practically unlimited row counts (billions feasible).
• Schema flexibility — columns can vary per row to a degree.
• Limited query language — no joins, simpler filtering.
• Limited extensibility — fewer plugin/workflow events.
• Time-to-live (TTL) per row for automatic expiration.

When elastic tables make sense.

• IoT telemetry and sensor data — high-frequency device readings.
• Audit logs and event streams — append-mostly workloads.
• Session and cache data — short-lived data with TTL.
• Transaction logs from external systems — bulk ingestion.
• AI conversation transcripts — high-volume, ephemeral data.

When standard tables remain the right choice.

• Master data (accounts, contacts, products).
• Transactional records that participate in business processes.
• Data needing complex queries (joins, aggregations, calculated columns).
• Data needing extensive workflow / plugin extensibility.
• Most CRM-style entities.

Creating an elastic table. In the maker portal:

1. New table → Advanced options → Table type: Elastic.
2. Define columns.
3. Configure partition key (more on this below).
4. Save and publish.

The table appears alongside standard tables but with different capabilities.

Partition key. Elastic tables require a partition key column. This is how Cosmos DB physically distributes data across nodes. Good partition keys:

• Have high cardinality (many distinct values).
• Distribute load evenly (no "hot partition").
• Match common query patterns (queries within a partition are fast).

A bad partition key concentrates all writes on one partition, defeating the throughput advantage. Picking it well is the single most important elastic table decision.

Query patterns.

• Single-row read by primary key — fastest.
• Within-partition queries — fast, comparable to standard.
• Cross-partition queries — slow, expensive in RU/s terms.
• Aggregations — limited; do them in Power BI or a downstream pipeline.

The mental model: elastic tables are great for "ingest fast, look up by key, never join."

Time-to-live (TTL). Each row can have a TTL column; Cosmos automatically deletes rows past their expiration. For ephemeral data (session logs, temporary captures), TTL eliminates the housekeeping work of periodic cleanup jobs.

Limited business logic. Elastic tables support fewer:

• Plugins — limited events.
• Workflows — limited operations.
• Business rules — limited support.
• Real-time flows — limited triggers.

For most elastic use cases (high-volume ingest), this is fine — business logic should happen downstream, not on the ingest path.

Cost model. Cosmos DB pricing is request unit (RU) based. Reads and writes consume RUs; throughput is provisioned. Dataverse abstracts this but the cost scales with throughput, not just storage. Elastic table cost can be substantial under high load — budget accordingly.

Migration. Standard ↔ elastic isn't a switch; data needs migration. Plan the table type at design time.

Integration with the rest of Dataverse.

• Foreign keys to standard tables work in limited ways — elastic doesn't enforce relationships the way standard does.
• Reports and Power BI read elastic data via standard Dataverse connectors.
• Power Automate can trigger on elastic table changes.

Common pitfalls.

• Using elastic for general business data. "It's faster" reasoning, but workflows, joins, and audit needs make it inappropriate.
• Bad partition key choice. Hot partition → throughput collapses; redesign required.
• Forgetting RU cost. High-throughput scenarios incur material cost; monitor and budget.
• Treating elastic as drop-in standard. Queries fail or perform terribly; rewrites needed.
• No TTL on temporal data. Rows accumulate forever; cost rises.

Operational recommendation. Default to standard tables. Move to elastic tables only when standard performance limits are demonstrably reached or when the use case clearly matches the elastic strength profile (high-volume ingest, ephemeral data, simple queries). The hybrid pattern — elastic for ingest, replicate aggregations to standard for query and reporting — works well at scale.