Is it safe to configure Lock Escalation as 'AUTO' for partitioned tables

LOCK_ESCALATION= AUTO. In one of our Data warehousing product we use partitioned tables. They are partitioned based on an integer column. We have implemented partitioning here so we can easily switch data across tables. Environment Details:

SQL Version: SQL Server 2016
Table: FACT
Approx Size: 100-500 GB
No of Partitions: 100
Partition Column: RunID (int)

Activity: Parallel ETL Processing
Applications Involved in ETL: SSIS package We have a SSIS Package which is written to process in parallel for 3 RunIDs (3 Partitions). These 3 runs are few minutes/hours apart from each other. We have faced a situation where we observe a time-out when below condition occurs. Below is the observation: Run 3 (Truncate seems to be blocked for an hour) Run 2 (Bulk Insert, this is timed-out) We Suspect either Run2 or Run1 is conflicting with Run3, eventually causing a time-out for Run2. | Run 3 | Run 2 | | -------- | -------- | | Truncate with partition | Bulk insert | | partion 3 | Partion 2 | To avoid this conflict, we are considering to set the Lock Escalation of this partitioned table to AUTO. So, the locks would remain at HoBT level. While we are processing concurrently for 3 different Partitions. https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-table-transact-sql?view=sql-server-ver16#set--lock_escalation---auto--table--disable-- Before Implementing, we wanted an opinion to understand the risks associated by using this configuration for a particular table which is only Queried/Processed for one partition at a time. Could this change introduce deadlocks? Since the early adopters of this feature have experienced deadlocks: Paul Randal: https://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-2330-lock-escalation/ Brent Ozar: https://www.brentozar.com/archive/2017/11/partition-level-locks-confusing/