Elastic tables

What it does

An elastic table is a Dataverse table backed by Azure Cosmos DB rather than the relational store. Same maker experience, same API surface, very different engine — built for datasets in the tens of millions of rows with high write throughput and automatic expiry.

Key facts

Elastic table data counts against your Dataverse log capacity, not database capacity.
Time to live is set in seconds on the row, measured as a delta from last modified. When it expires the row is deleted automatically.
No multi-record transactions. A synchronous plug-in failing on PostOperation won't roll back the created row. Pre-operation validation plug-ins still work as expected.
Strong consistency only within a logical session. Outside that session context you might not immediately see a change you just made.
You can't filter on related-table columns in views, advanced find or API queries. The documented workaround is denormalising the columns you filter on into the main table.
Supported: CRUD including the multiple-operation messages, bulk delete, one-to-many relationships, many-to-one where the N side is a standard table, record ownership, change tracking, auditing, mobile offline, Dataverse search, file columns, and both user/organisation ownership plus column-level security.
Not supported: alternate keys, N:N to standard tables, calculated and rollup columns, currency columns, formula columns, business rules, business process flows, charts, duplicate detection, table sharing, access teams, queues, connections, attachments, composite indexes, all cascade operations, and import/export of table data.
Bulk operation messages (CreateMultiple, UpdateMultiple, DeleteMultiple) are how you get throughput within the same service protection limits — Microsoft cites roughly ten times the throughput of single requests.

When to use / skip

Elastic tables earn their place on high-volume, semi-structured, short-lived data: IoT telemetry, campaign coupons, event streams, staging data that arrives by the million and expires by the million. The isolation from the relational store is the real prize — that traffic doesn't drag your core tables down. Skip it for anything transactional, anything needing joins or complex filtering across relationships, and anything a business user will build a chart on. The feature list you give up is long and most of it is stuff people assume is always there. If someone's reaching for elastic tables because a standard table "feels slow", fix the indexes and the queries first.

Configuration decisions

Whether the data volume genuinely justifies it, or whether this is a standard table with a retention policy.
The TTL value, and whether "deleted automatically after N seconds" matches the retention obligation you've been given.
Which columns to denormalise up front, because you can't filter across relationships later.
Whether the write path uses bulk messages from day one — retrofitting them into an integration is real work.
How the data leaves the table before it expires, if anyone downstream needs it.

Gotchas

Rows removed by TTL after they've synchronised to a data lake through Azure Synapse Link stay in the lake. Your lake and your table diverge silently.
Point-in-time restore doesn't restore updates, because updates aren't backed up. Only created and deleted rows come back.
Deleting a column doesn't clear its data from existing rows. Clear the data first, then delete the column, or you leave orphaned values behind.
No alternate keys means no upsert by business key. Integration teams who've built their pattern around upsert have to change it.
The transaction model catches developers out. A plug-in that "protects" a write on a standard table does nothing of the sort here.

Consultant notes

Position elastic tables as a specific tool for a specific shape of data, not as the fast version of Dataverse. The unsupported list is what the conversation should be about.
Get the log capacity conversation in early. This is a different capacity bucket from the one the client has been watching, and it moves quickly at these volumes.
Warn that TTL is a hard delete with no recycle bin. If retention is a compliance requirement, the archive has to be built and proven before TTL is switched on.
Push for a proof of concept with realistic volumes. The unsupported features tend to surface as surprises during build, and it's much cheaper to hit them in week two.

Worth checking again as the unsupported feature list shortens — it's been shrinking release by release.