Is there guidelines on the amount of data that can be exported to BYOD before we need to consider Azure data lake? We have some very large tables/entites (think Docuref, vendtrans, etc.) that have millions of rows, or multiple GB in size, we prefer to access all the data via TSQL so exporting to BYOD seems simplest/most logical for us. However one of our D365 developers said initialization or re-initialization can be unreliable or costly in terms of time/hours and is not easy to troubleshoot if something goes wrong. For example, if there is an issue with change tracking for, say, Docuref table or entity, and we had to reinitialize, it may take many hours.
As we are not in production yet, I cannot test/verify this, so I'm looking for guidance.
Is not on table size or entity number of fields, but on critical tables.
I already got feedback from MS that "General Ledger Entries", "InventTrans", don't have support for incremental changes. It works, but we detected some SQL locking on those tables associated with change tracking
thank you nunomaia - is performance issue unsupported for large tables only, or does that include large entities as well?
I don't think there are any official guidelines on that topic. You should consider that many large tables ( ex: InventTrans ), if you enable change tracking and you open a performance ticket in Microsoft, you will get an answer that changing tracking in that table is not supported by Microsoft. Whenever possible use a datalake, for data extractions. For small databases, BYOD is simpler to manage and avoids many of the overhead that datalake has.
André Arnaud de Cal...
291,969
Super User 2025 Season 1
Martin Dráb
230,842
Most Valuable Professional
nmaenpaa
101,156