I work for a saas company that uses multi tenancy by a tenant_id, however we perform nightly jobs that dump mass amount of data from the last day of each tenant, sometimes we face deadlocks or simply locks that makes all operations run slow due to shared tables between tenants. Are there any alternatives to this problem besides using a DB per tenant to avoid DUI locks due to shared tables?
Without specific details on individual examples of locking and / or deadlocking issues you're facing, there's not much of a dedicated answer that can be provided. If you're aware of a specific case or two that is particularly troublesome, especially with the deadlocks, providing the queries, DDL of the entities involved, the deadlock graphs, and the execution plans, in a targeted question, would all be very useful to trying to improve those particular cases.
That being said, a general potential fix you could look into is changing the isolation level on the database to something more conducive to your locking tolerance. By default SQL Server uses the Read Committed isolation level, which employs pessimistic concurrency - essentially writers blocking readers and other writers during data changes. One particular isolation level you might be interested in is called Read Committed Snapshot Isolation aka RCSI.
RCSI helps reduce locks during concurrency of
SELECT statements by using row versioning to preserve the data at different points in time. This comes at the tradeoff of additional resource overhead on the server, generally with
tempdb. It is considered optimistic concurrency by nature.
You may find these additional readings on RCSI informative: